WO2025116789A1

WO2025116789A1 - Improved load sharing in ethernet-based fronthaul networks

Info

Publication number: WO2025116789A1
Application number: PCT/SE2023/051195
Authority: WO
Inventors: Balázs VARGA; Per-Erik Eriksson; Eduardo Lins De Medeiros; Gyanesh PATRA; János FARKAS; Igor Almeida
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-11-28
Filing date: 2023-11-28
Publication date: 2025-06-05
Anticipated expiration: 2026-05-28

Abstract

The present disclosure relates to a method of a transport network node (13a) of performing load balancing in a transport network (10), and a transport network node (13a) performing the method. In an aspect, a method of a transport network node (13a) of performing load balancing in a transport network (10) is provided. The method comprises receiving (S101) a data traffic flow to be transmitted over the transport network (10) from a source radio access network, RAN, node (11a) to a destination RAN node (12a) connecting to the transport network (10), identifying (S102) a plurality of data traffic sub-flows forming the data traffic flow from the source RAN node (11a) to the destination RAN node (12a), determining (S103) one or more routing paths via which the identified data traffic sub-flows can be transmitted to a next-hop node(13b, 13g) in the transport network (10) and if there are multiple possible routing paths, alternating (S104) the transmission of identified data traffic sub-flows from the data traffic flow via determined different routing paths to attain load balancing in the transport network (10).

Description

IMPROVED LOAD SHARING IN ETHERNET-BASED FRONTHAUL NETWORKS

TECHNICAL FIELD

[0001] The present disclosure relates to a method of a transport node of performing load balancing in a transport network, and a transport network node performing the method.

BACKGROUND

[0002] Today’s radio access networks (RANs) undergo a significant transformation in fifth generation/ sixth generation (5G/ 6G) mobile networks. From transport network perspective, one of the major changes is the usage of packet-based connectivity between RAN components, such as so-called radio units (RUs) and distributed units (DUs).

[0003] Due to the increased traffic volume between the RAN components over the transport network, load balancing becomes important and there is room for improvement in the transport network load balancing.

SUMMARY

[0004] One objective is to solve, or at least mitigate, this problem in the art and thus to provide an improved method of a transport network node of performing load balancing in a transport network.

[0005] This objective is attained in a first aspect by a method of a transport network node of performing load balancing in a transport network. The method comprises receiving a data traffic flow to be transmitted over the transport network from a source radio access network (RAN) node to a destination RAN node connecting to the transport network, identifying a plurality of data traffic sub-flows forming the data traffic flow from the source RAN node to the destination RAN node, determining one or more routing paths via which the identified data traffic sub-flows can be transmitted to a next -hop node in the transport network and if there are multiple possible routing paths, alternating the transmission of identified data traffic sub-flows from the data traffic flow via determined different routing paths to attain load balancing in the transport network. [0006] This objective is attained in a second aspect by a transport network node configured to perform load balancing in a transport network, said transport network node comprising a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the transport network node is operative to receiving a data traffic flow to be transmitted over the transport network from a RAN node to a destination RAN node connecting to the transport network, identifying a plurality of data traffic sub-flows forming the data traffic flow from the source RAN node (na) to the destination RAN node, determining one or more routing paths via which the identified data traffic sub-flows can be transmitted to a next-hop node in the transport network and if there are multiple possible routing paths, alternating the transmission of identified data traffic sub-flows from the data traffic flow via determined different routing paths to attain load balancing in the transport network.

[0007] Thus, the transport network node identifies, for the data traffic flow to be sent between the source RAN node and the destination RAN node, e.g. a first subflow and a second sub-flow and then determines one or more routing paths via which the identified data traffic sub-flows can be transmitted to a next-hop transport node in the transport network. The transport network node may thus send the first subflow via a first routing path while sending the second sub-flow via a second routing path. By alternating the transmission of the identified data traffic sub-flows via different routing paths, a better load balancing is advantageously attained in the transport network.

[0008] In an embodiment, a sub-flow is identified by identifying from a message header of a data frame a Real-Time Control Data Identifier (RTC_ID) in case of control plane traffic and a Physical Channel Identifier (PC_ID) in case of user plane traffic.

[0009] In an embodiment, the source RAN node is identified by identifying from a message header of a data frame a source media access control (MAC) address and the destination RAN node being identified by identifying from a message header of a data frame a destination MAC address.

[0010] In an embodiment, the message header is an evolved Common Public Radio Interface (eCPRI) protocol message header. [oon] In an embodiment, the source RAN node and the destination RAN node is identified from a destination address identifying the destination RAN node and the source RAN node as a pair of RAN nodes between which the data traffic flow is communicated.

[0012] In an embodiment, the transport network node being a transport network edge node.

[0013] In an embodiment, the receiving further comprises receiving an output of a hash function in which at least an identifier of a data traffic sub-flow and a destination RAN node address has been hashed by the source RAN node, wherein the identifying of a plurality of data traffic sub-flows being performed by identifying the plurality of data traffic sub-flows from the received hash function output.

[0014] In an embodiment, the source RAN node further includes the source RAN node address in the hash.

[0015] In an embodiment, the identifying of a plurality of data traffic sub-flows is performed by deriving an identifier of a data traffic sub-flow from a Customer Virtual local area network Identification (C-VID) in which the source RAN node has included the identifier of the data traffic sub-flow.

[0016] In an embodiment, the source RAN node is identified from a unique source RAN node identifier having been encoded by the source RAN node in the identifier of a data traffic sub-flow.

[0017] In a third aspect, a computer program is provided comprising computerexecutable instructions for causing a transport network node of the second aspect to perform steps recited in the method of the first aspect when the computer-executable instructions are executed on a processing unit included in the transport network node.

[0018] In a fourth aspect, a computer program product is provided comprising a computer readable medium, the computer readable medium having the computer program according to the third aspect embodied thereon.

[0019] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, in which:

[0021] Figure 1 illustrates a transport network in which embodiments may be implemented;

[0022] Figure 2 illustrates a radio base station comprising the transport network of Figure 1;

[0023] Figure 3 illustrates a prior art scenario of data traffic flows being transported in the transport network of Figure 1;

[0024] Figure 4 illustrates an exemplifying embodiment where the data traffic flows are more evenly distributed in the transport network of Figure 1 in order to attain better load balancing;

[0025] Figure 5 shows a flowchart illustrating a method according to an embodiment;

[0026] Figure 6 shows a flowchart illustrating a method according to a further embodiment;

[0027] Figure 7 shows a flowchart illustrating a method according to yet a further embodiment;

[0028] Figure 8 illustrates a device according to an embodiment; and

[0029] Figure 9 illustrates a network in which embodiments may be implemented.

DETAILED DESCRIPTION

[0030] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown.

[0031] These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0032] Figure 1 illustrates a transport network 10 where data traffic flows in the form of data packets are distributed between RUs and DUs in a RAN. The data packets are transported in uplink from the RUs to the DUs and in downlink from the DUs to the RUs over the transport network 10 commonly referred to as a fronthaul network. As will be described embodiment may be implemented in the transport network 10 of Figure 1.

[0033] Thus, illustrated in Figure 1 is a fronthaul network 10 via which RAN components in the form of the RUs 11a, 11b, 11c, nd and the DUs 12a, 12b communicated with each other via transport nodes I3a-i3g (embodied e.g. in the form of routers) arranged in the fronthaul network 10 and interconnected by means of various network links.

[0034] As is understood, the RUs and the DUs form part of a radio base station (RBS), in a 5G mobile network referred to as a gNodeB (gNB).

[0035] Wireless communication devices 14a, 14b, 14c connected to the RAN, e.g. a user equipment (UE) in the form of for instance a smart phone, tablet, desktops gaming console, connected vehicle, etc., and served by the gNB communicates with the gNB via the RUs na-nd for transmitting data via the transport nodes I3a-i3g of the transport network 10 to the DUs 12a, 12b and further to a core network and on to e.g. the Internet.

[0036] Figure 2 illustrates such gNB 20 communicating with a neighbouring gNB 21 over an Xn interface. The gNBs 20, 21 form part of a RAN referred to as New Generation (NG) RAN in 5G. Control plane signal paths are illustrated with dotted lines while user plane signal paths are illustrated with continuous lines.

[0037] The gNB 20 comprises a central unit (CU) being split into a CU-CP 22 (“control plane”) and a CU-UP 23 (“user plane”) being interconnected over an El interface.

[0038] The CU-CP 22 connects to an AMF 24 of the 5G core (5GC) network over interface N2, the AMF 24 providing UE-based authentication, authorization, mobility management, etc. Note that only selected components of the 5GC network will be described in the following. The AMF 24 carries control plane signalling via Nil to a Session Management Function (SMF) 25 configured to perform session management, e.g. session establishment, modify and release, etc., which in its turn connects via N4 to a User Plane Function (UPF) 26 being a service function that processes user plane packets; processing may include altering the packet’s payload and/or header, interconnection to data network(s), packet routing and forwarding, etc., while the CU-UP 23 connects to a data network 27, such as the Internet, over N6 via N3 interface and the UPF 26 for transporting user data.

[0039] Further, the CU-CP 22 connects to the DUs 12a, 12b (DU) via interface Fi- C and further to the UEs 143-140 via evolved Common Public Radio Interface (eCPRI) and the RUs na-nd communicating over wireless interface Uu, while the CU-UP 23 connects to the DUs 12a, 12b via interface Fi-U and further to the UEs 143-140 via interface eCPRI, the RUs na-nd and the wireless interface Uu.

[0040] Hence, the RU is a radio hardware unit configured to convert radio signals sent to and from an RU antenna into a digital signal for transmission over a packet data network connecting the RUs to the DUs. The DU provides support for the protocol stack lower layers of such as radio link control (RLC), media access control (MAC) and physical layer. Even though the RU and the DU both functionally form part of the gNB, the two components may nevertheless be located many kilometres from each other.

[0041] As mentioned, with the increased traffic volume in current mobile networks, load balancing in the packet -based fronthaul/ transport networks becomes important.

[0042] Layer 2 (i.e. data link) networks such as e.g. Ethernet, in which embodiments maybe implemented, use a so-called bridging technology to forward packets in the fronthaul network to be described in the following.

[0043] Figure 3 illustrates a prior art scenario where data traffic flows in the form of data packets are distributed over the transport network 10 of Figure 1 between the RUs and the DUs. In the following example, uplink transmission from the RUs to the DUs will be described. [0044] As indicated by the dotted line, a first data traffic flow is transmitted from first RU na over the first transport node 13a, second transport node 13b, third transport node 13c and fourth transport node 13d before finally reaching first DU 12a.

[0045] As indicated by the dash-dotted line, a second data traffic flow is transmitted by second RU 11b over fifth transport node 13c, the second transport node 13b, sixth transport node I3f and the fourth transport node 13d before finally reaching second DU 12b.

[0046] As is understood, Figure 3 is for illustration only, and in practice a gNB transports hundreds or thousands of data traffic flows over the fronthaul network 10.

[0047] In the prior art illustrated in Figure 3, the routing of data from an RU to a DU, such as from the first RU 11a to the first DU 12a, is based on concept of hashing to preserve the order of the data packets of each flow such that a recipient may handle the data packets in the order in which they initially were sent.

[0048] The current practice in the RAN illustrated in Figure 1 is to use a dedicated virtual local area network (VLAN) for communication between the RUs and DUs. To achieve load balancing, the input of the hashing function can be the following Ethernet header fields: destination-MAC / source-MAC / VLAN -ID.

[0049] However, with this method all data traffic flows formed by the data packets sent between an RU and a DU (and vice versa) is treated as a single data traffic flow communicated via a single path over the network 10, and that single path will thus be highly loaded with traffic.

[0050] The part of the fronthaul network 10 being closest to the RUs is generally referred to as Low-RAN (L-RAN) while the part of the fronthaul network 10 being closest to the DUs is referred to as High-RAN (H-RAN). The prior art approach illustrated with reference to Figure 1 results in poor performance in the L-RAN and results in mitigated effectiveness in H-RAN.

[0051] Rather, it would be desirable to achieve a better load balancing and thus to transport the data traffic flows such that not all flows follow the same single path through the transport network 10.

[0052] To resolve this issue, the data packet traffic flows are in an embodiment divided into smaller sub-flows which then can be sent over different links in the fronthaul network 10 to achieve better load balancing. [0053] Figure 4 illustrates an exemplifying embodiment where the data traffic flows are more evenly distributed in the transport network 10 in order to attain better load balancing.

[0054] Reference will further made to Figure 5 showing a flowchart illustrating a method according to an embodiment.

[0055] To achieve the load balancing, each data traffic flow to be transmitted over the fronthaul network 10 from an RU to a DU (and vice versa) is identified in S102 upon being received in S101 at a transport node I3a-i3g in the fronthaul network 10 forwarding the traffic flow to a next -hop transport node.

[0056] Thus, upon e.g. the first transport node 13a receiving a data traffic flow from the first RU 11a intended for the first DU 12a in S101, the first transport node 13a will in S102 identify a plurality of data traffic sub-flows forming the data traffic flow from the first RU 11a to the first DU 12a.

[0057] In an embodiment, this identification is performed by the first transport node 13a masking out a parameter referred to as Physical Channel Identifier (PC_ID) from the Ethernet frame in case the data packets being transmitted relates to user plane data or Real-Time Control Data Identifier (RTC_ID) in case of control plane data.

[0058] As previously mentioned, the protocol used in the fronthaul network 10 for communicating between the RUs and the DUs is referred to as the eCPRI protocol and the RTC_ID/PC_ID identifies payload data of each Ethernet frame. These two identifiers are located in a fixed position of the eCPRI message header.

[0059] Hence, with reference to Figure 4, assuming that the first transport node 13a identifies - for the data traffic flow to be sent between the first RU 11a and the first DU 12a - a first sub-flow associated with PC_IDi acquired by masking the eCPRI message header of an Ethernet frame and a second sub-flow associated with PC_ID2 of a masked eCPRI message header of another Ethernet frame.

[0060] In S103, the first transport node 13a determines one or more routing paths via which the identified data traffic sub-flows PC_IDi, PC_ID2 can be transmitted to a next-hop transport node in the transport network 10.

[0061] In this particular example, the first transport node 13a may either send a sub-flow to the second transport node 13b or to seventh transport node 13g, and selects to send the first sub-flow PC_IDi as indicated by the dotted line to the second transport node 13b which will perform the same process as the first transport node 13a and in this case determine that the sub-flow identified by PC_IDi is to be sent to the third transport node 13c which in its turn sends the sub-flow PC_ID1 to the fourth transport node 13d (in this example, the third transport node 13c does not have any other routing alternatives), which ultimately send the sub-flow to the first DU 12a to which the sub-flow is intended. That is, the same route as in Figure 3 is taken.

[0062] Conversely, upon sending the second sub-flow PC_ID2, the first transport node 13a will (as indicated by the dotted line) send the second sub-flow PC_ID2 to the seventh transport node 13g in S104.

[0063] Thus, by alternating the transmission of identified data traffic sub-flows PC_IDi, PC_ID2 via different routing paths in S104, better load balancing is attained in the transport network.

[0064] As further shown, the seventh transport node 13g sends the second subflow PC_ID2 to the second transport node 13b (the seventh transport node 13g does not have any routing alternatives), which in its turn sends the second sub-flow PC_ID2 to the sixth transport node I3f. As is understood, the third transport node 13c would have been a possible next -hop transport node instead of the sixth transport node 13b but a better load balancing is achieved by selecting the sixth transport node I3f. The sixth transport node I3f then sends the second sub-flow PC_ID2 to the fourth transport node 13d which finally delivers the second sub-flow PC_ID2 to the first DU 12a.

[0065] Advantageously, as illustrated in Figure 4, the method of this embodiment clearly provides for a far better load balancing.

[0066] Similarly, as illustrated by the dash-dot lines, a first sub-flow PC_IDi forming part of a data traffic flow to be sent from the second RU 11b to the second DU 12b is sent over the fifth transport node 13c, the second transport node 13b, the sixth transport node 13b the fourth transport node 13d and finally to the second DU 12b (as previously shown in Figure 3), while in this embodiment a second sub-flow PC_ID2 forming part of the data traffic flow to be sent from the second RU 11b to the second DU 12b is sent over the fifth transport node 13c, the second transport node 13b, the third transport node 13c, the fourth transport node 13d and finally to the second DU 12b. Again, a far better load balancing is advantageously achieved.

[0067] While in the embodiment above all transport nodes I3a-i3g determines alternative routing paths to a next-hop transport node and alternates the transmission of sub-flows in case it is possible to choose different routing paths for the sub-flows.

[0068] However, it may in another embodiment be envisaged that only edge transport nodes 13a, 13d, 13c and 13g in the transport network 10 performs the routing approach according to the embodiment described hereinabove.

[0069] As described, in order to identify a plurality of sub-flows PC_ID1, PC_ID2 forming a greater traffic flow between an RU and a DU (or vice versa), the transport nodes should determine the source RU and the destination DU (or vice versa). Again, in an embodiment, this may be performed by identifying from the eCPRI message header a source address and a destination address of the Ethernet frame. These are encoded in the message header as source MAC address (src_MAC) and destination MAC (dst_MAC).

[0070] It may further be envisaged that with the advent of virtualization and cloud technologies in some scenarios, the source MAC address may not be needed, as the destination MAC address (of the virtualized DU) can be representative for the RU/DU pair.

[0071] Thus, in an embodiment described above, each transport node will need at least the PC_ID (or the RTC_ID in case of control plane data) as well as the source address and the destination address, or the destination address alone if the destination address also indicates the source address, or at least that the source device maybe identified from the destination address.

[0072] Figure 6 shows a flowchart illustrating a further embodiment of allowing an RU/DU to identify sub-flows in order to route the sub-flows for improving load balancing in the transport network 10.

[0073] As mentioned, it may be envisaged that a hashing function is utilized for providing routing information in the transport network 10. In this embodiment, a hashing function is utilized for indicating to a transport node the PC_ID, src_MAC and dst_MAC rather than having each transport node mask the eCPRI message header for extracting the routing information. If so, it is envisaged in an embodiment that the RAN components connected to the transport network 10, i.e. the RUs na-nd in the uplink and the DUs 12a, 12b in the downlink, mask the routing information from the eCPRI header and inputs the masked routing information to the hashing function in S100, wherein the transport nodes advantageously only need to read the hashing output in S102 to determine the PC_ID, src_MAC and dst_MAC:

Hout = H(PC_ID, src_MAC, dst_MAC)

[0074] The hashing function output Hout may be attached to each set of payload data carried by an Ethernet frame, wherein the transport nodes only need to read and interpret the hashing function output Hout rather than masking the eCPRI message header to extract the routing information and in particular for identifying the subflows forming a greater traffic flow between the RUs and the DUs.

[0075] Figure 7 shows a flowchart illustrating yet a further embodiment of allowing an RU/DU to identify sub-flows in order to route the sub-flows for improving load balancing in the transport network 10.

[0076] In this embodiment, the RAN components interfacing with the transport network, i.e. the RUs or the DUs will identify the RTC_ID/PC_ID (i.e. the RUs in the uplink and the DUs in the downlink) from the eCPRI message header and include the identified RTC_ID/PC_ID in another Ethernet message header data field referred to as Customer VLAN Identification (C-VID).

[0077] In such embodiment, the transport nodes will identify each sub-flow from the C-VID in which the RTC_ID/PC_ID is encoded. Again, the RU/DU may perform the hashing as Hout = H(C-VID, src_MAC, dst_MAC).

[0078] In a further embodiment, with reference again to Figure 3, the RTC_ID/PC_ID are allocated independently to the eCPRI message header for each Ethernet frame by the RU/DU.

[0079] Thus, it may happen that two RUs sending a data traffic flow in the uplink to one or more DUs allocate the same PC_ID to one or more sub-flows. In order to avoid any mix-up at a transport node identifying the sub-flows, the two RUs further encode their unique ID in the RTC_ID/PC_ID field.

[0080] In addition to avoiding any mix-up at the transport nodes of sub-flows having the same PC_ID but originating from different RUs, there is no need for the transport nodes to further mask out src_MAC since the identifier of (in this case) the source RU is included in the RTC_ID/PC_ID field, for example using the MSB bits in the RTC_ID/PC_ID field.

[0081] Figure 8 illustrates a transport network node 13a (such as e.g. a routing device) configured to perform load balancing in a transport network according to an embodiment. The steps of the method performed by the transport network node 13a are in practice performed by a processing unit 811 embodied in the form of one or more microprocessors arranged to execute a computer program 812 downloaded to a storage medium 813 associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit 811 is arranged to cause the transport network node 13a to carry out the method according to embodiments when the appropriate computer program 812 comprising computerexecutable instructions is downloaded to the storage medium 813 and executed by the processing unit 811. The storage medium 813 may also be a computer program product comprising the computer program 812. Alternatively, the computer program 812 maybe transferred to the storage medium 813 by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program 812 maybe downloaded to the storage medium 813 over a network. The processing unit 811 may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. The transport network node 13a further comprises a communication interface 814 (wired or wireless) over which it is configured to transmit and receive data.

[0082] The transport network node 13a according to embodiments may be provided as a standalone device or as a part of at least one further device. Alternatively, functionality of the transport network node 13a may be distributed between at least two devices, or nodes, such as a number of virtual machines.

[0083] Thus, a first portion of the actions performed by the transport network node 13a maybe executed in a first device, and a second portion of the actions performed maybe executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the actions performed by the transport network node 13a may be executed. [0084] Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a device residing in a cloud computational environment. Therefore, although a single processing circuitry 810 is illustrated in Figure 8, the processing circuitry 810 maybe distributed among a plurality of devices, or nodes.

[0085] Figure 9 illustrates a network in the form of an Open RAN 101 (O-RAN), in which embodiments maybe implemented. For example, the method maybe implemented in one or more network nodes in a transport network located between the O-RU 800 and the O-DU 700.

[0086] With reference to the O-RAN 101, the role of a Non-Real Time RAN intelligent controller (RIC) 200 is among other things, such as providing a service management and orchestration framework, to serve one or more radio base stations 300 (i.e. RAN sites) referred to as O-eNB via 01 interface and to provide high-level control signals to Near-Real Time RICs 400 via Al interface; such signals include but not limited to policy-based guidance, machine-learning (ML) model management, and enrichment of data. The role of Near-Real Time RICs 400 is to perform low-level control signals to O-RAN compatible network elements including the one or more O- eNBs 300, O-CU-CP 500, O-CU-UP 600 and O-DU 700 via E2 interface. Further included is an O-RU 800 connected to the O-DU 700 via a control, user and synchronization (CUS) plane as well as via a management (M) plane, and an O-Cloud 900, i.e. a cloud platform. The embodiments that has been described in detail hereinabove may thus advantageously be implemented in a transport network node of the transport network located between the O-RU 800 and the O-DU 700.

[0087] The aspects of the present disclosure have mainly been described above with reference to a few embodiments and examples thereof. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

[0088] Thus, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1. A method of a transport network node (13a) of performing load balancing in a transport network (10), comprising: receiving (S101) a data traffic flow to be transmitted over the transport network (10) from a source radio access network, RAN, node (11a) to a destination RAN node (12a) connecting to the transport network (10); identifying (S102) a plurality of data traffic sub-flows forming the data traffic flow from the source RAN node (11a) to the destination RAN node (12a); determining (S103) one or more routing paths via which the identified data traffic sub-flows can be transmitted to a next-hop node (13b, 13g) in the transport network (10); and if there are multiple possible routing paths: alternating (S104) the transmission of identified data traffic sub-flows from the data traffic flow via determined different routing paths to attain load balancing in the transport network (10).

2. The method of claim 1, a sub-flow being identified by identifying from a message header of a data frame a Real-Time Control Data Identifier, RTC_ID, in case of control plane traffic and a Physical Channel Identifier, PC_ID, in case of user data traffic.

3. The method of any one of the preceding claims, the source RAN node (11a) being identified by identifying from a message header of a data frame a source media access control, MAC, address and the destination RAN node (12a) being identified by identifying from a message header of a data frame a destination MAC address.

4. The method of any one of claims 2 or 3, the message header being an evolved Common Public Radio Interface, eCPRI, protocol message header.

5. The method of any one of the preceding claims, the source RAN node (11a) and the destination RAN node (12a) being identified from a destination address identifying the destination RAN node (12a) and the source RAN node as a pair of RAN nodes between which the data traffic flow is communicated.

6. The method of any one of the preceding claims, the transport network node (13a) being a transport network edge node.

7. The method of any one of the preceding claims, the receiving (Sioi) further comprising: receiving an output of a hash function in which at least an identifier of a data traffic sub-flow and a destination RAN node address has been hashed (Sioo) by the source RAN node (12a); wherein the identifying (S102) of a plurality of data traffic sub-flows being performed by: identifying the plurality of data traffic sub-flows from the received hash function output.

8. The method of claim 7, the source RAN node (12a) further including the source RAN node address in the hash.

9. The method of any one of the preceding claims, the identifying (S102) of a plurality of data traffic sub-flows being performed by: deriving an identifier of a data traffic sub-flow from a Customer Virtual local area network Identification, C-VID, in which the source RAN node (11a) has included (Siooa) the identifier of the data traffic sub-flow.

10. The method of any one of the preceding claims, the source RAN node (11a) being identified from a unique source RAN node identifier having been encoded by the source RAN node (11a) in the identifier of a data traffic sub-flow.

11. A computer program (812) comprising computer-executable instructions for causing a transport network node (13a) to perform steps recited in any one of claims 1-10 when the computer-executable instructions are executed on a processing unit (811) included in the transport network node (13a).

12. A computer program product comprising a computer readable medium (813), the computer readable medium having the computer program (812) according to claim 11 embodied thereon.

13. A transport network node (13a) configured to perform load balancing in a transport network (10), said transport network node (13a) comprising a processing unit (811) and a memory (813), said memory containing instructions (812) executable by said processing unit (811), whereby the transport network node (13a) is operative to: receiving (S101) a data traffic flow to be transmitted over the transport network (10) from a source radio access network, RAN, node (11a) to a destination RAN node (12a) connecting to the transport network (10); identifying (S102) a plurality of data traffic sub-flows forming the data traffic flow from the source RAN node (11a) to the destination RAN node (12a); determining (S103) one or more routing paths via which the identified data traffic sub-flows can be transmitted to a next-hop node (13b, 13g) in the transport network (10); and if there are multiple possible routing paths: alternating (S104) the transmission of identified data traffic sub-flows from the data traffic flow via determined different routing paths to attain load balancing in the transport network (10).

14. The transport network node (13a) of claim 13 being operative to identify a subflow by identifying from a message header of a data frame a Real-Time Control Data Identifier, RTC_ID, in case of control plane traffic and a Physical Channel Identifier, PC_ID, in case of user data traffic.

15. The transport network node (13a) of claims 13 or 14 being operative to identify the source RAN node (11a) by identifying from a message header of a data frame a source media access control, MAC, address and the destination RAN node (12a) being identified by identifying from a message header of a data frame a destination MAC address.

16. The transport network node (13a) of claims 14 or 15, the message header being an evolved Common Public Radio Interface, eCPRI, protocol message header.

17. The transport network node (13a) of any one of claims 13-16 being operative to identify the source RAN node (11a) and the destination RAN node (12a) from a destination address identifying the destination RAN node (12a) and the source RAN node as a pair of RAN nodes between which the data traffic flow is communicated.

18. The transport network node (13a) of any one of claims 13-17, the transport network node (13A) being a transport network edge node.

19. The transport network node (13a) of any one of claims 13-18, further being operative to, upon receiving (S101) a data traffic flow: receiving an output of a hash function in which at least an identifier of a data traffic sub-flow and a destination RAN node address has been hashed (S100) by the source RAN node (12a); wherein the identifying (S102) of a plurality of data traffic sub-flows being performed by: identifying the plurality of data traffic sub-flows from the received hash function output.

20. The transport network node (13a) of any one of claims 13-19, the source RAN node (12a) further including the source RAN node address in the hash.

21. The transport network node (13a) of any one of claims 13-20, further being operative to, upon identifying (S102) a plurality of data traffic sub-flows: deriving an identifier of a data traffic sub-flow from a Customer Virtual local area network Identification, C-VID, in which the source RAN node (11a) has included (Siooa) the identifier of the data traffic sub-flow.

22. The transport network node (13a) of any one of claims 13-21 being operative to identifying the source RAN node (11a) from a unique source RAN node identifier having been encoded by the source RAN node (11a) in the identifier of a data traffic sub-flow.