Method and switch for managing traffic in transport network

Abstract

A method for managing traffic of a plurality of packets in a plurality of packet flows transmitted using a time-slotted interface. The packet flows traverse a plurality of switches of a transport network according to an assigned path from a source node to a destination node. The method comprises determining an end-to-end latency of a plurality of packets traversing a current switch in packet flows and assigning priority values to the packets traversing the current switch, wherein a priority value of a packet depends on the determined end-to-end latency of said packets. The method further comprises allocating a time slot in an output interface of the current switch to the packet having the highest priority value among the packets competing for said time slot.

Claims

1. A method for managing traffic of a plurality of packets in a plurality of packet flows transmitted using a time-slotted interface, the packet flows traversing a plurality of switches of a transport network according to an assigned path from a source node to a destination node, the method comprising: determining an end-to-end latency of a plurality of packets traversing a current switch in packet flows; assigning priority values to the packets traversing the current switch, wherein a priority value of a packet depends on the determined end-to-end latency of the packets; and allocating a time slot in an output interface of the current switch to the packet having the highest priority value among the packets competing for the time slot.

2. The method of claim 1, wherein the determined end-to-end latency includes latency introduced by the current switch.

3. The method of claim 1, wherein the determining the end-to-end latency comprises considering switching delay introduced by the switches along the path and ignoring propagation delay.

4. The method of claim 1, wherein the assigning priority values to the packets traversing the current switch comprises applying weighting factors based on class of service associated with the packets.

5. The method of claim 1, wherein operations of the method are applied separately within each class of service associated with the packets.

6. The method of claim 1, wherein operations of the method are applied to packets having the same class of service.

7. The method of claim 1, wherein end points of the traffic traversing the plurality of switches include at least one baseband unit (BBU) and a plurality of remote radio units (RRUs) or Radio Baseband Units (RBUs).

8. The method of claim 1, wherein packets of the packet flows are transported in the transport network encapsulated as payload in Ethernet frames.

9. The method of claim 1, further comprising recording, in a dedicated information field associated with a packet traversing the current switch, the determined end-to-end latency for this packet.

10. A switch for forwarding packets to a network node of a transport network, the packets traversing the transport network according to an assigned path from a source node to a destination node, the switch comprising: a plurality of input/output ports connected to a switching matrix, processing circuitry operatively connected to the plurality of input/output ports; memory containing instructions executable by the processing circuitry whereby the switch is operative to: determine end-to-end latency of a plurality of packets traversing the switch in packet flows; assign priority values to packets traversing the switch, wherein a priority value of a packet depends on the determined end-to-end latency of the packet; and allocate a time slot in an output interface of the switch to the packet having the highest priority value among the packets competing for the time slot.

11. The switch of claim 10, wherein the determined end-to-end latency includes latency introduced by the switch.

12. The switch of claim 10, wherein the instructions are such that the switch is operative, in assigning priority values to the packets traversing the switch, to apply weighting factors based on class of service associated with the packets.

13. The switch of claim 10, wherein end points of the packets traversing the switch include at least one baseband unit (BBU) and a plurality of remote radio units (RRUs) or Radio Baseband Units (RBUs).

14. The switch of claim 10, wherein the instructions are such that the switch is operative to record, in a dedicated information field of a packet traversing the switch, the determined end-to-end latency for this packet.

15. A centralized network element for orchestrating forwarding of packets in a transport network, the packets traversing the transport network according to an assigned path from a source node to a destination node, the centralized network element comprising: a communication interface for connecting to a plurality of switches in the network; processing circuitry operatively connected to the communication interface; memory containing instructions executable by the processing circuitry whereby the centralized network element is operative to: determine end-to-end latency of a plurality of packets traversing a switch in packet flows; instruct the switch to assign priority values to packets traversing the switch, wherein a priority value of a packet depends on the determined end-to-end latency of the packet; and instruct the switch to allocate a time slot in an output interface of the switch to the packet having the highest priority value among the packets competing for the time slot.

16. A transport network, comprising: a plurality of switches connecting at least one baseband unit (BBU) and a plurality of remote radio units (RRUs) or Radio Baseband Units (RBUs); wherein the plurality of switches are configured to manage traffic of a plurality of packets in a plurality of packet flows transmitted using a time-slotted interface, the packet flows traversing the plurality of switches of the transport network according to an assigned path from a source node to a destination node; wherein the plurality of switches are configured to manage the traffic by: determining an end-to-end latency of a plurality of packets traversing a current switch in packet flows; assigning priority values to the packets traversing the current switch, wherein a priority value of a packet depends on the determined end-to-end latency of the packets; and allocating a time slot in an output interface of the current switch to the packet having the highest priority value among the packets competing for the time slot.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with the drawings in which:

(2) FIG. 1 is a diagram illustrating Ethernet packet including a latency budget field in one embodiment of the present invention;

(3) FIG. 2A is a flowchart illustrating a method for managing traffic in one embodiment of the present invention;

(4) FIG. 2B is a flowchart illustrating a method for managing traffic in one embodiment of the present invention;

(5) FIG. 3 is a diagram illustrating a fronthaul network operating in accordance with one embodiment of the present invention;

(6) FIG. 4 is a diagram illustrating a switch in one embodiment of the present invention;

(7) FIG. 5 is a flowchart illustrating a method for managing traffic in another embodiment of the present invention;

(8) FIG. 6 is a diagram illustrating a centralised network element for orchestrating forwarding of packets in a fronthaul network in one embodiment of the present invention;

(9) FIG. 7 is a diagram illustrating a switch in an alternative embodiment of the present invention;

(10) FIG. 8 is a diagram illustrating a centralised network element for orchestrating forwarding of packets in a fronthaul network in an alternative embodiment of the present invention.

DETAILED DESCRIPTION

(11) In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the invention with unnecessary details.

(12) Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

(13) In order to clarify the terminology used in this document and in this technical field we will refer to the schematic drawing illustrated in FIG. 3. Here we can identify two locations where elements of distributed radio base stations are placed: Antenna side—in FIG. 3, it is the place on the left with the antenna icons and elements marked as RBU1-RBU5. Central office or, in other words, the centralized place where all or part of the baseband processing is done. In FIG. 3 these are P1 and P2.

(14) In the scenario shown in FIG. 3 and later described in this document these two places are geographically separated and connected by a transport network also referred to, as explained earlier, as Fronthaul Interface or fronthaul network.

(15) What is located at the antenna side is named as Radio Equipment (RE). RE is a term originating from the CPRI specification. Geographical distribution of the functions of a Radio Base Station may be implemented in different ways. In some implementations the Radio Equipment may comprise a Remote Radio Unit (RRU) in alternative implementations the Radio Equipment may perform some baseband processing then the RE is referred to as Radio Baseband Unit (RBU).

(16) What is located at the central office is named as Radio Equipment Controller (REC). REC is similarly a term originating from the CPRI specification. Different names are used with reference to REC, for example Digital Unit (DU) or Baseband Unit (BBU).

(17) It is to be appreciated that whichever terms are used with reference to the Radio Equipment and Radio Equipment Controller these elements are the source and destination nodes (end nodes) of end-to-end paths across the transport network with a plurality of nodes (switches) located between these end nodes. The invention now to be described in its embodiments is focused on managing traffic in the nodes (switches) located between these end nodes and therefore the model of distributing the functions between the RE and REC does not affect the way the present invention operates in its embodiments.

(18) The inventors have realised that one way of supporting the architecture for 5G networks discussed in the background section may be by using packets over a time-slotted interface. In such a time division technique a source is allowed to transmit packets only at fixed time slots. To allow for statistical multiplexing among multiple packet flows of this type, unlike CPRI, the packets are transmitted only in presence of real traffic. This, in turn, enables optimization opportunities in transport.

(19) In one embodiment the packets of the time-slotted interface outlined above are encapsulated as payload in a regular Ethernet frame, to manage all the features relevant to the transport network. Said packets may be encapsulated one packet per one Ethernet frame or multiple packets per one Ethernet frame.

(20) By considering a network of switches, which is the most challenging case (switches acting only at the wavelength level introduce negligible latency but might be bandwidth inefficient, as discussed in PCT/EP2015/077556) the problem we intend to solve is the contention of Ethernet frames entering in different input ports of the switch that try to share the same output port.

(21) For the sake of simplicity, in one embodiment, it is assumed that all the input Ethernet frames have the same class of service. In alternative embodiments different class of services can be managed on the top of the proposed mechanism as in regular Ethernet switches. Class of service of Ethernet frames is inherited from the one of the packet flows of the packets encapsulated in the Ethernet frames. In the description of the present solution Ethernet is used as a preferred embodiment because by using Ethernet it is possible to exploit its features (source address, destination address, class of service, etc.), but the solution described in this disclosure is really about addressing the problem of delivering packets of the time-slotted interface to destination in the same order as the packets have been sent from the source. Hence, in alternative embodiments a different technology may be used instead of Ethernet for encapsulating the packets of the time-slotted interface. Embodiments of the present invention are particularly advantageous in managing real-time or near real-time traffic, but are equally applicable to non-real-time traffic.

(22) The goal of the proposed solution is to ensure the lowest possible end-to-end latency for each packet flow by means of an intelligent handling of all the contentions happening at the output ports of each packet switch in the network.

(23) In the Ethernet frame, 100, encapsulating the packet of the time-slotted interface, it is proposed to introduce a latency budget field, 102, for example as part of the payload in order to avoid modifying the well consolidated Ethernet standard. This embodiment of an Ethernet frame according to the solution described in this document is illustrated in FIG. 1.

(24) In an alternative embodiment it is possible, however, to modify the Ethernet header by adding the latency budget field.

(25) Packets in the same flow can experience different latency values because these values depend on whether other traffic sources are transmitting or not. So the latency budget must be managed for each individual Ethernet frame encapsulating the packet. In embodiments in which we use a single Ethernet frame to encapsulate more than one packet latency budget fields must be allocated for each packet in the frame.

(26) In a preferred embodiment the latency budget field has two sub-fields: Accumulated latency: it is the sum of latency contributions of all the switches and links already traversed by the Ethernet frames. The accumulated latency is determined by measurement and/or estimation (e.g. fiber propagation contributions are estimated) at the input of each switch node. Forecasted latency: it is the estimated latency contribution of all links and nodes that the Ethernet frames have to cross before reaching its destination. For example, it can be estimated by the control plane, based on statistical measurements.

(27) The end-to-end latency being equal to a sum of accumulated latency and forecasted latency is used as a parameter to prioritize flows in situations when plurality of Ethernet frames with encapsulated packets request access to the same output line (output port) of the Ethernet switch—the higher the latency, the higher the priority. Initially, when the Ethernet frame with an encapsulated packet of the time-slotted interface enters the first switch after being transmitted by the source node, E2E latency is entirely based on the forecasted latency, while at the end of the path, i.e. at the last switch before the destination node, the E2E latency is equal to the accumulated latency.

(28) The mechanism can be easily modified to give different weights to packets having different class of service.

(29) With reference to FIG. 2A one embodiment of a method for managing traffic of a plurality of packets organised in a plurality of packet flows will be described. In this embodiment the packets are transmitted using a time-slotted interface and said packet flows traverse a plurality of switches according to an assigned path. In a preferred embodiment the method comprises determining end-to-end latency, 202, of a plurality of packets traversing a current switch in packet flows. The method further comprises assigning priority values, 204, to the packets traversing the current switch, wherein a priority value of a packet depends on the determined end-to-end latency of said packet and allocating a time slot, 206, in an output interface of the current switch to the packet having the highest priority value among the packets competing for said time slot.

(30) As illustrated in FIG. 2B determining the end-to-end latency, 202, preferably comprises determining an accumulated latency, 210, from a source node to the current switch and estimating a forecasted latency, 212, from the current switch to a destination node based on the path assigned to the packet flow. Finally, the end-to-end latency is calculated as a sum of the accumulated and forecasted latency values.

(31) In a preferred embodiment the operation of estimating the forecasted latency comprises determining an accumulated latency from the destination node to the current switch based on packets travelling from the destination node to the current switch. This is applicable in situations when the path between the current switch and the destination node is bi-directional. In this situation it is possible to use actual delay from the switches and links located ahead of the current switch. This still is an estimation, albeit more accurate, because at the time of using this information conditions in the network may change and it will be a historical information and not current.

(32) Preferably, the end-to-end latency determined at node C, for a given flow i, can be expressed by the sum of three contributions, where the generic intermediate node, in an E2E flow path, is indicated as the current node C:
{tilde over (L)}.sub.E2E(i,C)=L.sub.S,C(i)+L.sub.C(i)+{tilde over (L)}.sub.C,D(i)
where: L.sub.S,C(i) is the measured, accumulated, latency from S (source) to C for flow i; it has been cumulated in the nodes and links traversed on partial sub-path up to C. L.sub.C(i) is the latency which node C imposes on the flow; it is determined by a minimum traversing delay but can be incremented if other flows are prioritized. {tilde over (L)}.sub.C,D(i) is the estimated, forecasted, latency from C to D (destination); the final sub-path to reach the destination will introduce a further latency contribution and the component cumulated in the nodes is not deterministic.

(33) One can see that the latency estimation drops in significance as the current node C gets closer to the destination node because measurements prevail over estimations.

(34) The proposed method operates, at an individual node (switch), according to the following steps.

(35) TABLE-US-00001 For each node n of the network  For each flow i traversing node n     Calculate {tilde over (L)}.sub.E2E(i, n)  Next i  Transmit in the next slot the flow with maximum {tilde over (L)}.sub.E2E(i, n)  among all the flows traversing n Next n.

(36) The procedure is applied at an individual node (preferably each node traversed by the flow) by considering all the flows which are competing for an outgoing time-slot from the same output port on the node. In practice, the node scheduler assigns “the next slot” for outgoing transmission to the flow that is expected to cumulate the worse E2E latency (i.e. the highest latency) among all the flows that cross the node (switch) itself.

(37) By considering the overall network and the complete set of flows, the goal is to equalize as much as possible the E2E latencies of all the flows.

(38) Preferably, determining the end-to-end latency comprises considering switching delay introduced by the switches along the path and ignoring propagation delay. This may be advantageous in certain situations. For example, if a first flow has to travel for 1 km and a second one for 10 km to the current switch taking into account propagation delay would unnecessarily penalize the first flow.

(39) In another embodiment assigning priority values to the packets traversing the current switch comprises applying weighting factors based on class of service associated with the packets. This embodiment reflects the fact that one traffic flow may be more important than other traffic flow and their relative importance (reflected by the class of service) may be an additional factor to consider.

(40) In a preferred embodiment the operations of the method are applied separately within each class of service associated with the packets. In this embodiment all the traffic in the current switch is split into separate streams depending on their class of service and then the operations of the method are applied separately for each class off service. In this way each class of service is processed independently from the other classes. This embodiment has the advantage that it does not affect the established hierarchy of the classes of service, but rather improve managing of packet flows within individual class of service. In a modification of this embodiment the operations of the method are applied to packets having the same class of service. This alternative embodiment allows for leaving out a certain class of service from managing as described above. The certain class of service may for example be a low-priority, pre-emptible traffic served on best effort basis. The advantage of this embodiment is that processing resources in the current switch will be saved (not used on processing low priority traffic), which will improve performance of the switch.

(41) As mentioned earlier, in a preferred embodiment packets of the packet flows are transported in the fronthaul network encapsulated as payload in Ethernet frames. In alternative embodiments other network transport interface may be used instead of Ethernet. A fronthaul network in this document is a transport network connecting elements of a distributed Radio Base Station, i.e. connecting RE and REC as discussed earlier and illustrated in FIG. 3.

(42) As illustrated in FIG. 5, the method preferably comprises recording, 502, in a dedicated information field associated with a packet traversing the current switch the determined end-to-end latency for this packet. In a preferred embodiment in which payload of an Ethernet frame, 100, is used to transport the packet of the time-slotted interface the dedicated information field, 102, associated with the packet is also inserted in the payload of the Ethernet frame 100. This is illustrated in FIG. 1. The determined end-to-end latency may be recorded as separate values for accumulated latency and forecasted latency; alternatively it may be recorded as separate values for accumulated latency, forecasted latency and latency imposed by the current switch. In yet another embodiment in the dedicated information field the determined end-to-end latency may be recorded as a single total value including the components discussed above.

(43) As the Ethernet frame with the encapsulated packet of the time-slotted interface travels along the path towards the destination node the recording of the determined end-to-end latency comprises updating the information about the determined end-to-end latency carried in said dedicated information field from a previous switch.

(44) In a particularly advantageous embodiment the method comprises requesting, 506, from a path computation element to re-route a particular path to a destination node if network conditions do not guarantee fulfilling end-to-end latency needs, 504. In particular the re-routing of the particular path to the destination node may be requested, 506, if the determined end-to-end latency is at or above a threshold, 504. The advantage of this embodiment is that not only it allows for improved management of packet flows along a predefined path, but also allows for reacting to changing network conditions and re-routing once the network conditions deteriorate and expected performance cannot be guaranteed.

(45) In another embodiment this document discloses a network of switches, where an individual switch in the network is adapted to operate according to the method described above. In a preferred embodiment all switches in the network are adapted to operate according to this method. In alternative embodiment only some of the switches operate in accordance with this method. The switches which are not capable of processing the latency information switch Ethernet frames with encapsulated packets in the same way as well known switches and the switches capable of handling the latency information will assign priority based on the End-to-End latency information. In other words, the switches which are not capable of processing the latency information will simply ignore the latency information and the switches capable for processing the latency information will determine the components of the end-to-end latency using estimation where it is not possible to get measurements. An embodiment of the network operating in accordance with the method described in this document is illustrated in FIG. 3.

(46) FIG. 3 illustrates a scenario of a (partially) centralized baseband processing based on Radio Baseband Units, RBUs, operating as Radio Equipment (RE) and Baseband Units, BBUs, operating as Radio Equipment Controllers (RECs). As explained earlier RE and REC are elements of a distributed Radio Base Station where the controller (REC) comprising at least some baseband processing functions are centralised and serve plurality of remotely located RE elements. The RBUs and BBUs communicate via packet flows over a time-slotted interface. Five macro sites, with their RBUs, RBU1-RBU5, are on the left. In the embodiment illustrated in FIG. 3 the end points of the traffic traversing the plurality of switches include six baseband units, BBUs, and five Radio Baseband Units, RBU1-RBU5. The six BBUs are located in two baseband hotels located on the right in two sites labeled as P1 and P2. A packet network comprising twelve nodes N1-N12 is located in-between. A baseband hotel is also known as baseband pool—radio frequency heads at base station sites are connected over high speed link, e.g. optical fibre to a baseband pool. The packet flows from RBUs to BBUs are considered an uplink (UL), while the packet flows in the opposite direction are considered a downlink (DL).

(47) In an alternative embodiment Remote Radio Units (RRUs) may operate as the Radio Equipment instead of the RBUs and then the BBUs in the two baseband hotels P1 and P2 would perform all the baseband processing for the RRUs.

(48) In a preferred embodiment all the input data are frequency synchronous and have the same bit rate. They are time synchronized at the input of each switch (max introduced latency=1 encapsulated frame).

(49) Each flow is transmitted from a source node S, traverses a sequence of nodes Nx and a sequence of links connecting said nodes, and finally terminates a destination node D. Nodes Nx and links introduce latencies on each flow. In a preferred embodiment link latencies are considered fixed for each link and traffic independent.

(50) As disclosed earlier priority of Ethernet frames processed by the switch is inherited from the packets encapsulated in these frames. The same is true for relationship between latency of the packets and Ethernet frames.

(51) In a preferred embodiment determining the end-to-end latency comprises adding latency imposed by the individual switch to the accumulated latency and the forecasted latency.

(52) In the example illustrated in FIG. 3 two packet flows are transmitted: Flow A, marked with a dotted line and with letter A, from RBU1 to one of the BBUs in P1. Flow B, marked with a dotted line and with letter B, from RBU3 to one of the BBUs in P2.

(53) In FIG. 3 the notation L1,4,A refers to latency on the link between nodes N1 and N4 experienced by flow A; the notation D1,A refers to switching delay experienced by flow A at node N1. The same notation scheme is applicable throughout FIG. 3.

(54) The paths used by flow A and flow B share nodes N6 and N10 and the link in between. Let's focus on node N6 first.

(55) The two flows compete for a time slot on the outgoing port of N6 towards N10. The flow having the higher expected E2E latency will be prioritized. The two latencies are:
{tilde over (L)}.sub.E2E(A,N6)=L.sub.RBU1,N6(A)+L.sub.N6(A)+{tilde over (L)}.sub.N6,P1(A)
and
{tilde over (L)}.sub.E2E(B,N6)=L.sub.RBU2,N6(B)+L.sub.N6(B)+{tilde over (L)}.sub.N6,P1(B)
where: L.sub.RBU1,N6(A) is the measured latency between RBU1 and N6 {tilde over (L)}.sub.N6,P1(A) is the estimated latency between N6 and P1 L.sub.RBU2,N6(B) is the measured latency between RBU2 and N6 {tilde over (L)}.sub.N6,P2(B) is the estimated latency between N6 and RBU2.

(56) In the hypothesis that {tilde over (L)}.sub.E2E (A, N6)>{tilde over (L)}.sub.E2E(B, N6) the determined end-to-end latency for flow A is higher than corresponding determined end-to-end latency for flow B and node N6 will prioritize flow A with respect to flow B. As a consequence L.sub.N6(A) will be less than L.sub.N6(B), where L.sub.N6(B) and L.sub.N6(A) is the latency imposed by N6 on flow A and flow B respectively. As can be seen from the analysis flow A will have priority over flow B and this is why latency imposed by switch N6 onto flow B will be higher than latency imposed on flow A.

(57) It is assumed, in a preferred embodiment, that each flow is bi-directional and the two directions are operated on the same E2E path. Optionally, latency values in one direction, in a specific node, for a specific flow, can be used to improve the accuracy of the estimation for the same flow, in the same node, in the opposite direction.

(58) In case that current network condition do not allow to fulfill E2E latency needs of a given flow, a feedback can be done to a path computation element to consider a re-routing of said flow to a less congested end-to-end path.

(59) In alternative embodiments nodes not implementing the method may be included in the network. In this case the latencies introduced by these not compatible nodes will be measured or estimated and then considered in the calculations done for the compatible nodes, implementing the method. In this way, the method can contribute to smooth differentials in end-to-end latencies even in partially legacy networks.

(60) With reference to FIG. 4 an embodiment of a switch adapted to operate in accordance with the method described in this document is now to be described.

(61) Illustrated in FIG. 4 is a preferred embodiment of the switch, 400, adapted to operate in accordance with the method described above. The switch, 400, comprises a plurality if input/output ports, 408-410, connected to a switching matrix, 406, a processor, 402, and a memory, 404. Said memory, 404, contains instructions executable by said processor, 402. Said switch 400, upon executing said instructions is operative to determine end-to-end latency of a plurality of packets traversing the switch, 400, in packet flows and assign priority values to packets traversing the switch, 400, wherein a priority value of a packet depends on the determined end-to-end latency of said packet. The switch, 400, is further operative to allocate a time slot in an output interface of the switch to the packet having the highest priority value among the packets competing for said time slot.

(62) The switch, 400, is operative to forward packets to a network node of a fronthaul network, for example another switch or a destination node, like Radio Equipment (e.g. RRU or RBU) or Radio Equipment Controller (e.g. DU or BBU). The packets traverse the fronthaul network according to an assigned (or predefined) path from a source node to a destination node.

(63) In a preferred embodiment in determining the end-to-end latency the switch, 400, is operable to determine an accumulated latency from the source node to the switch and to estimate a forecasted latency from the switch to the destination node based on the path assigned to the packet flow. The switch is also operable to calculate the end-to-end latency as the sum of the accumulated and forecasted latency values.

(64) In a preferred embodiment the packets are encapsulated in frames of a transport interface, for example Ethernet, and the latency and priority are determined for the frames carrying the encapsulated packets.

(65) In a preferred embodiment Ethernet is used as the time-slotted interface, but in alternative embodiments instead of Ethernet other time-slotted transport technologies may be used.

(66) Path computation methodology, for flows traversing the network, is out of scope of the present disclosure. It is assumed that the method applies to a set of flows which paths have been calculated in advance, as it is done in many optical networks. In an alternative embodiment the proposed method is compatible with a network architecture in which a centralized entity, such as an orchestrator, for example, has a full visibility of the latency contributions of nodes and links. The orchestrator also computes the estimates and forecasts. The orchestrator itself can manage the priority list for each node and determine the next flow in line for each node. Preferably, class of services can also be considered as an additional parameter used to determine flow priorities by the orchestrator.

(67) With reference to FIG. 6 an embodiment of a centralised network element adapted to operate in accordance with the method described in this document is now to be described.

(68) Illustrated in FIG. 6 is a preferred embodiment of the centralised network element, 600, for orchestrating forwarding of packets in a fronthaul network adapted to operate in accordance with the method described above. In embodiments in which the centralized network element 600 is used packets traverse the fronthaul network according to an assigned path from a source node to a destination node. The centralised network element, 600, comprises a processor, 602, a memory, 604, and a communication interface, 606, for connecting to a plurality of switches in the network. Said memory, 604, contains instructions executable by said processor, 602, whereby said centralised network element, 600, is operative to determine end-to-end latency of a plurality of packets traversing a switch in packet flows and to instruct the switch to assign priority values to packets traversing the switch, wherein a priority value of a packet depends on the determined end-to-end latency of said packet. Further, said centralised network element, 600, is operative to instruct the switch to allocate a time slot in an output interface of the switch to the packet having the highest priority value among the packets competing for said time slot.

(69) With reference to FIG. 7 an alternative embodiment of a switch, 700, operating in accordance with the embodiments of the method described in this document, is disclosed. The switch 700 is for forwarding packets to a network node of a transport network and the packets traverse the transport network according to an assigned path from a source node to a destination node. The switch 700 comprises a plurality of input/output ports, 704-706, connected to a switching matrix, 702. The switch 700 further comprises means, 710, for determining end-to-end latency of a plurality of packets traversing the switch in packet flows and means, 712, for assigning priority values to packets traversing the switch, 700. A priority value of a packet depends on the determined end-to-end latency of said packet. The switch 700 further comprises means, 714, for allocating a time slot in an output interface of the switch to the packet having the highest priority value among the packets competing for said time slot.

(70) In one embodiment the means 710, 712 and 714 are controlled by a controller means 708. In another alternative embodiment (not illustrated) said means 710, 712 and 714 are implemented as functions provided by the controller 708. In yet another embodiment said means 710, 712 and 714 as well as the switching matrix 702 are connected to a communication bus (not illustrated) and exchange data and control messages over this communication bus.

(71) With reference to FIG. 8 and alternative embodiment of a centralised network element, 800, for orchestrating forwarding of packets in a transport network is disclosed. The packets traverse the transport network according to an assigned path from a source node to a destination node. In a preferred embodiment the centralised network element 800 comprises a communication interface, 810, for connecting to a plurality of switches in the network. The centralised network element also comprises means 804 for determining end-to-end latency of a plurality of packets traversing a switch in packet flows and means, 806, for instructing the switch to assign priority values to packets traversing the switch. In a preferred embodiment a priority value of a packet depends on the determined end-to-end latency of said packet. The centralised network element, 800, further comprises means, 808, for instructing the switch to allocate a time slot in an output interface of the switch to the packet having the highest priority value among the packets competing for said time slot.

(72) In one embodiment said means 804, 806 and 808 are implemented as functions provided by the controller 802. In an alternative embodiment (not illustrated) the means 804, 806 and 808 are controlled by a controller 802, wherein the means 804, 806 and 808 and the controller 802 are implemented as separate modules. In yet another embodiment said means 804, 806 and 808 as well as the communication interface 810 are connected to a communication bus (not illustrated) and exchange data and control messages over said communication bus.

(73) The centralised network element, 800, is adapted to operate in accordance with the embodiments of the method described earlier.