Load sharing improvement in ethernet-based fronthaul networks

Abstract

The present disclosure relates to a method of a transport network node (13a) performing load balancing in a transport network (10) and a transport network node (13a) performing the method. On the one hand, a method of a transport network node (13a) performing load balancing in a transport network (10) is provided. The method comprises receiving (S101) a data traffic flow to be transmitted through the transport network (10) from a source radio access network (RAN) node (11a) to a destination RAN node (12a) connected with 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, transmitting (S104) the identified data traffic sub-flows in the data traffic flow via the determined different routing paths alternately to implement load balancing in the transport network (10).

Description

Technical Field

[0001] This disclosure relates to a method for a transport node to perform load balancing in a transport network and a transport network node that performs the method. Background Technology

[0002] Today's radio access networks (RANs) have undergone significant changes in fifth-generation (5G) / sixth-generation (6G) mobile networks. From the perspective of the transport network, one of the main changes is the use of packet-based connections between RAN components, such as so-called radio units (RUs) and distributed units (DUs).

[0003] As traffic increases between RAN components via the transport network, load balancing becomes critical, and there is room for improvement in transport network load balancing. Summary of the Invention

[0004] One objective is to address or at least mitigate this problem in the art, thereby providing an improved method for transport network nodes to perform load balancing in a transport network.

[0005] In a first aspect, the objective is achieved by a method for a transport network node to perform load balancing in a transport network. The method includes: receiving a data traffic flow to be transmitted from a source radio access network (RAN) node to a destination RAN node connected to the transport network; identifying multiple 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 through which the identified data traffic sub-flows can be transmitted to a next-hop node in the transport network; and, if multiple possible routing paths exist, alternately transmitting the identified data traffic sub-flows in the data traffic flow via the determined different routing paths to achieve load balancing in the transport network.

[0006] In a second aspect, this objective is achieved by a transmission network node configured to perform load balancing in a transmission network, the transmission network node including a processing unit and a memory containing instructions executable by the processing unit, thereby enabling the transmission network node to: receive a data traffic flow to be transmitted from a source radio access network (RAN) node to a destination RAN node connected to the transmission network via the transmission network; identify multiple data traffic sub-flows forming a data traffic flow from the source RAN node (11a) to the destination RAN node; determine one or more routing paths through which the identified data traffic sub-flows can be transmitted to a next-hop node in the transmission network; and, if multiple possible routing paths exist, alternately transmit the identified data traffic sub-flows in the data traffic flow via the determined different routing paths to achieve load balancing in the transmission network.

[0007] Therefore, the transport network node identifies the data traffic flow (e.g., a first sub-flow and a second sub-flow) to be transmitted between the source RAN node and the destination RAN node, and then determines one or more routing paths through which the identified data traffic sub-flow can be sent to the next-hop transport node in the transport network. Thus, the transport network node can send the first sub-flow via the first routing path and simultaneously send the second sub-flow via the second routing path. By alternately sending the identified data traffic sub-flows via different routing paths, better load balancing is advantageously achieved in the transport network.

[0008] In the embodiments, in the case of control plane services, sub-streams are identified by recognizing the Real-time Control Data Identifier (RTC_ID) from the message header of the data frame; in the case of user plane services, sub-streams are identified by recognizing the Physical Channel Identifier (PC_ID) from the message header of the data frame.

[0009] In this embodiment, the source RAN node is identified by recognizing the source Media Access Control (MAC) address from the message header of the data frame, and the destination RAN node is identified by recognizing the destination MAC address from the message header of the data frame.

[0010] In this embodiment, the message header is the Evolved Common Public Radio Interface (eCPRI) protocol message header.

[0011] In this embodiment, the source RAN node and the destination RAN node are identified from the destination address, which identifies the destination RAN node and the source RAN node as a pair of RAN nodes through which the data service flow is transmitted.

[0012] In this embodiment, the transmission network node is a transmission network edge node.

[0013] In this embodiment, receiving further includes: receiving the output of a hash function, in which the source RAN node has performed a hash operation on at least the identifier of the data service sub-stream and the address of the destination RAN node, wherein multiple data service sub-streams are identified by identifying multiple data service sub-streams from the received hash function output.

[0014] In this embodiment, the source RAN node also includes the source RAN node address in the hash.

[0015] In this embodiment, identification of multiple data service sub-flows is performed by deriving identifiers of data service sub-flows from the Customer Virtual LAN Identifier (C-VID), wherein the source RAN node already includes the identifiers of the data service sub-flows.

[0016] In this embodiment, the source RAN node is identified from a unique source RAN node identifier, which has been encoded by the source RAN node into the identifier of the data service sub-flow.

[0017] In a third aspect, a computer program including computer-executable instructions is provided, which, when executed on a processing unit included in a transmission network node, cause the transmission network node of the second aspect to perform the steps described in the method of the first aspect.

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

[0019] Generally, unless otherwise expressly stated herein, all terms used in the claims are to be interpreted according to their ordinary meaning in the art. Unless otherwise expressly stated, all references to “a / an / element, device, component, apparatus, step, etc.” are to be openly interpreted as referring to at least one instance of an element, device, component, apparatus, step, etc. Unless expressly stated otherwise, the steps of any method disclosed herein need not be performed in the exact order disclosed. Attached Figure Description

[0020] Aspects and embodiments will now be described with reference to the accompanying drawings, in which:

[0021] Figure 1 A transmission network capable of implementing various embodiments is shown;

[0022] Figure 2 It shows including Figure 1 Radio base stations of the transmission network;

[0023] Figure 3 It shows Figure 1 Existing technological scenarios for data service flows transmitted in transmission networks;

[0024] Figure 4 This shows the data service flow in Figure 1 An exemplary embodiment of more evenly distributed load in the transmission network to achieve better load balancing;

[0025] Figure 5 A flowchart of a method according to an embodiment is shown;

[0026] Figure 6 A flowchart of a method according to another embodiment is shown;

[0027] Figure 7 A flowchart of a method according to yet another embodiment is shown;

[0028] Figure 8 A device according to an embodiment is shown; and

[0029] Figure 9 A network in which embodiments can be implemented is shown. Detailed Implementation

[0030] Aspects of this disclosure will now be described more fully below with reference to the accompanying drawings, in which certain embodiments of the invention are illustrated.

[0031] However, these aspects may be manifested 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 will fully convey aspects of the invention to those skilled in the art. Throughout this specification, similar reference numerals refer to similar elements.

[0032] Figure 1 The diagram illustrates a transport network 10 in which data traffic flows in the form of data packets are distributed between RUs and DUs within the RAN. Data packets are transmitted from RUs to DUs in the uplink and from DUs to RUs in the downlink via transport network 10 (often referred to as the fronthaul network). The ability to... Figure 1 An embodiment implemented in the transmission network 10.

[0033] therefore, Figure 1 The diagram shows a fronthaul network 10, through which RAN components in the form of RUs 11a, 11b, 11c, 11d and DUs 12a, 12b communicate with each other via transmission nodes 13a to 13g (e.g., embodied in the form of routers) arranged in the fronthaul network 10 and interconnected by various network links.

[0034] It is understandable that RU and DU form part of a radio base station (RBS) (referred to as gNodeB (gNB) in 5G mobile networks).

[0035] Wireless communication devices 14a, 14b, 14c (e.g., smartphones, tablet computers, game consoles, user equipment (UEs) in the form of connected vehicles) connected to the RAN and served by the gNB communicate with the gNB via RUs 11a to 11d to transmit data to DUs 12a, 12b via transmission nodes 13a to 13g of the transmission network 10 and further to the core network, and finally to, for example, the Internet.

[0036] Figure 2This illustrates a gNB 20 communicating with its neighboring gNB 21 via the Xn interface. gNBs 20 and 21 form part of the RAN (referred to as the Next Generation (NG) RAN) in 5G. Control plane signal paths are shown with dashed lines, while user plane signal paths are shown with solid lines.

[0037] The gNB 20 includes a central unit (CU) which is split into CU-CP 22 (“control plane”) and CU-UP 23 (“user plane”) interconnected via an E1 interface.

[0038] CU-CP 22 connects to the AMF 24 of the 5G core (5GC) network via interface N2. AMF 24 provides UE-based authentication, authorization, mobility management, etc. Note that only selected components of the 5GC network will be described below. AMF 24 transmits control plane signaling via N11 to the Session Management Function (SMF) 25, which is configured to perform session management (e.g., session establishment, modification, and release). The SMF 25 is then connected via N4 to the User Plane Function (UPF) 26, which is a service function that processes user plane packets. Processing may include changing packet payloads and / or headers, interconnection with data networks, packet routing and forwarding, etc. CU-UP 23 connects to the data network 27 (e.g., the Internet) via interface N3 and UPF 26 through N6 to transmit user data.

[0039] In addition, CU-CP 22 is connected to DU 12a, 12b (DU) via interface F1-C and further connected to UE 14a to 14c via Evolved Common Public Radio Interface (eCPRI) and RU 11a to 11d communicating via radio interface Uu, while CU-UP 23 is connected to DU 12a, 12b via interface F1-U and further connected to UE 14a to 14c via interface eCPRI, RU 11a to 11d, and radio interface Uu.

[0040] Therefore, an RU is a radio hardware unit configured to convert radio signals sent to and from the RU antenna into digital signals for transmission over a packet data network connected by RUs and DUs. The DU provides support for lower layers of the protocol stack, such as Radio Link Control (RLC), Media Access Control (MAC), and the physical layer. Although both RUs and DUs are functionally part of a gNB, these two components can still be located thousands of meters apart.

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

[0042] The Layer 2 (i.e., data link) network (e.g., Ethernet) that can implement the embodiments uses so-called bridging techniques to forward packets in the fronthaul network, which will be described below.

[0043] Figure 3 This illustrates the data service flow in the form of data packets. Figure 1 The following describes a prior art scenario where a transport network 10 distributes data between a RU and a DU. The uplink transport from the RU to the DU will be described in the following example.

[0044] As shown by the dashed line, the first data service flow is sent from the first RU 11a through the first transmission node 13a, the second transmission node 13b, the third transmission node 13c and the fourth transmission node 13d, and finally arrives at the first DU 12a.

[0045] As shown by the dotted line, the second data service flow is transmitted from the second RU 11b through the fifth transmission node 13e, the second transmission node 13b, the sixth transmission node 13f, and the fourth transmission node 13d, and finally reaches the second DU 12b.

[0046] Understandable. Figure 3 For illustrative purposes only; in reality, the gNB transmits hundreds or thousands of data traffic streams through the fronthaul network 10.

[0047] exist Figure 3 In the prior art shown, the routing of data from RU to DU (e.g., from the first RU 11a to the first DU 12a) is based on the concept of performing a hash operation to maintain the order of data packets for each stream, so that the receiver can process the data packets in the order in which they were initially sent.

[0048] Figure 1 The current practice in the RAN shown is to use a private Virtual Local Area Network (VLAN) for communication between RUs and DUs. To achieve load balancing, the input to the hash 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 data packets sent between RU and DU (and vice versa) are treated as a single data traffic flow communicating through a single path via network 10, and therefore this single path will bear a high traffic load.

[0050] In the fronthaul network 10, the portion closest to the RU is typically referred to as the low RAN (L-RAN), while the portion closest to the DU is referred to as the high RAN (H-RAN). (Reference) Figure 1 The existing technology method shown leads to poor performance in L-RAN and a degraded effect in H-RAN.

[0051] Instead, the expectation is to achieve better load balancing so that data traffic flows are not all routed through the same single path via the transport network 10.

[0052] To address this issue, in this embodiment, the data packet service flow is divided into smaller sub-flows, which can then be sent through different links in the fronthaul network 10 to achieve better load balancing.

[0053] Figure 4 An exemplary embodiment is shown in which data traffic flows are distributed more evenly in the transport network 10 to achieve better load balancing.

[0054] Further reference Figure 5 , Figure 5 A flowchart of a method according to an embodiment is shown.

[0055] In order to achieve load balancing, when each data service flow is received at transmission nodes 13a to 13g in the fronthaul network 10 from RU to DU (or vice versa) via the fronthaul network 10 in S101, each data service flow is identified in S102 so as to forward the service flow to the next hop transmission node.

[0056] Therefore, when, for example, in S101, the first transmission node 13a receives a data service flow for the first DU 12a from the first RU 11a, in S102, the first transmission node 13a will identify multiple data service sub-flows that form the data service flow from the first RU 11a to the first DU 12a.

[0057] In this embodiment, the identification is performed by masking parameters from the Ethernet frame by the first transmission node 13a. These parameters are referred to as Physical Channel Identifier (PC_ID) if the data packet being transmitted involves user plane data, or as Real-Time Control Data Identifier (RTC_ID) if the data packet being transmitted involves control plane data.

[0058] As previously mentioned, the protocol used for communication between the RU and DU in the fronthaul network 10 is called the eCPRI protocol, and the RTC_ID / PC_ID identifies the payload data of each Ethernet frame. These two identifiers are located in fixed positions in the eCPRI message header.

[0059] Therefore, refer to Figure 4Assume that for a data service flow to be transmitted between the first RU 11a and the first DU 12a, the first transmission node 13a identifies a first subflow associated with PC_ID1 obtained by masking the eCPRI message header of an Ethernet frame and a second subflow associated with PC_ID2 of the masked eCPRI message header of another Ethernet frame.

[0060] In S103, the first transmission node 13a determines one or more routing paths, and the identified data service sub-streams PC_ID1 and PC_ID2 can be sent to the next-hop transmission node in the transmission network 10 via the one or more routing paths.

[0061] In this specific example, the first transport node 13a can send the sub-flow to either the second transport node 13b or the seventh transport node 13g, and chooses to send the first sub-flow PC_ID1 indicated by the dashed line to the second transport node 13b (which will perform the same process as the first transport node 13a). In this case, it is determined that the sub-flow identified by PC_ID1 will be sent to the third transport node 13c, which in turn sends the sub-flow PC_ID1 to the fourth transport node 13d (in this example, the third transport node 13c has no other routing alternatives). The fourth transport node 13d ultimately sends the sub-flow to the first DU 12a to which the sub-flow is targeted. That is, adopting the same approach as... Figure 3 The same route as the one in the text.

[0062] Conversely, when sending the second sub-stream PC_ID2, in S104, the first transmission node 13a will (as shown by the dashed line) send the second sub-stream PC_ID2 to the seventh transmission node 13g.

[0063] Therefore, by alternately sending the identified data service sub-streams PC_ID1 and PC_ID2 via different routing paths in S104, better load balancing is achieved in the transmission network.

[0064] As further illustrated, the seventh transport node 13g sends the second sub-stream PC_ID2 to the second transport node 13b (the seventh transport node 13g has no alternative routing options), which in turn sends the second sub-stream PC_ID2 to the sixth transport node 13f. It can be understood that the third transport node 13c (instead of the sixth transport node 13f) could have been the next-hop transport node, but better load balancing is achieved by selecting the sixth transport node 13f. Then, the sixth transport node 13f sends the second sub-stream PC_ID2 to the fourth transport node 13d, which ultimately forwards the second sub-stream PC_ID2 to the first DU 12a.

[0065] Advantageously, such as Figure 4 As shown, the method in this embodiment clearly achieves much better load balancing.

[0066] Similarly, as shown by the dotted lines, the first sub-stream PC_ID1, which forms part of the data service flow from the second RU 11b to the second DU 12b, is sent through the fifth transmission node 13e, the second transmission node 13b, the sixth transmission node 13f, and the fourth transmission node 13d, and is finally sent to the second DU 12b (as previously shown). Figure 3 As shown in the diagram, in this embodiment, the second sub-stream PC_ID2, which forms part of the data service flow from the second RU 11b to the second DU 12b, is sent through the fifth transmission node 13e, the second transmission node 13b, the third transmission node 13c, and the fourth transmission node 13d, and is finally sent to the second DU 12b. Similarly, much better load balancing is advantageously achieved.

[0067] Meanwhile, in the above embodiments, all transmission nodes 13a to 13g determine alternative routing paths to the next-hop transmission node and alternately transmit sub-streams when they are able to select different routing paths for the sub-streams.

[0068] However, in another embodiment, it is conceivable that only the edge transmission nodes 13a, 13d, 13e and 13g in the transmission network 10 perform the routing method according to the above embodiment.

[0069] As previously mentioned, in order to identify multiple sub-flows PC_ID1, PC_ID2 that form a larger traffic flow between RU and DU (or vice versa), the transport node should determine the source RU and destination DU (or vice versa). Similarly, in this embodiment, this can be performed by identifying the source and destination addresses of the Ethernet frames from the eCPRI message header. These addresses are encoded in the message header as the source MAC address (src_MAC) and the destination MAC address (dst_MAC).

[0070] It can also be envisioned that with the emergence of virtualization and cloud technologies, in some scenarios, the source MAC address may not be needed because the destination MAC address (of the virtualized DU) can represent the RU / DU pair.

[0071] Therefore, in the above embodiments, each transmission node will need at least a PC_ID (or RTC_ID in the case of control plane data) as well as a source address and a destination address, or if the destination address also indicates the source address, then only the destination address is needed, or at least the source device can be identified from the destination address.

[0072] Figure 6 A flowchart is shown for another embodiment that allows RU / DU to identify sub-streams in order to route them, thereby improving load balancing in transport network 10.

[0073] As previously mentioned, it is conceivable to utilize a hash function to provide routing information in the transport network 10. In this embodiment, instead of having each transport node mask the eCPRI message header to extract the routing information, the hash function is used to indicate the PC_ID, src_MAC, and dst_MAC. If so, it is conceivable that in this embodiment, the RAN components connected to the transport network 10 (i.e., RUs 11a to 11d in the uplink and DUs 12a and 12b in the downlink) mask the routing information from the eCPRI header and input the masked routing information into the hash function in S100, whereby the transport node advantageously only needs to read the hash output in S102 to determine the PC_ID, src_MAC, and dst_MAC.

[0074] Hout = H(PC_ID, src_MAC, dst_MAC)

[0075] The hash function output Hout can be attached to each set of payload data carried by the Ethernet frame. The transmission node only needs to read and interpret the hash function output Hout instead of masking the eCPRI message header to extract routing information and specifically identify the sub-flows that form the larger traffic flow between RU and DU.

[0076] Figure 7 A flowchart is shown for yet another embodiment that allows RU / DU to identify sub-streams in order to route them, thereby improving load balancing in transport network 10.

[0077] In this embodiment, the RAN component (i.e., RU or DU) connected to the transport network interface will identify the RTC_ID / PC_ID (i.e., RU in the uplink and DU in the downlink) from the eCPRI message header and include the identified RTC_ID / PC_ID in another Ethernet message header data field called Customer VLAN Identifier (C-VID).

[0078] In this embodiment, the transport node will identify each substream from the C-VID encoded with RTC_ID / PC_ID. Similarly, the RU / DU can perform hash operations, such as Hout=H(C-VID,src_MAC,dst_MAC).

[0079] In another embodiment, refer again Figure 3 For each Ethernet frame, RU / DU independently assigns RTC_ID / PC_ID to the eCPRI message header.

[0080] Therefore, it is possible that two RUs sending data traffic flows to one or more DUs in the uplink will assign the same PC_ID to one or more sub-flows. To avoid any confusion when identifying sub-flows at the transport node, the two RUs further encode their unique IDs into the RTC_ID / PC_ID field.

[0081] Besides avoiding any confusion between substreams with the same PC_ID but originating from different RUs at the transport node, the transport node also does not need to further mask src_MAC, because (in this case) the identifier of the source RU is included in the RTC_ID / PC_ID field, for example, by using the MSB bit in the RTC_ID / PC_ID field.

[0082] Figure 8 A transport network node 13a (e.g., a routing device) configured to perform load balancing in a transport network according to an embodiment is illustrated. The method steps performed by the transport network node 13a are actually executed 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 (e.g., random access memory (RAM), flash memory, or hard disk drive) associated with the microprocessor. The processing unit 811 is arranged to cause the transport network node 13a to perform the method according to the embodiment when a suitable computer program 812, including computer-executable 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 including the computer program 812. Alternatively, the computer program 812 may be transferred to the storage medium 813 via a suitable computer program product, such as a digital universal disc (DVD) or memory stick. As another alternative, the computer program 812 may be downloaded to the storage medium 813 via a network. The processing unit 811 may alternatively be implemented as 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 transmission network node 13a also includes a (wired or wireless) communication interface 814, through which the transmission network node 13a is configured to send and receive data.

[0083] According to the embodiment, the transport network node 13a can be provided as a standalone device or as part of at least one other device. Alternatively, the functionality of the transport network node 13a can be distributed among at least two devices or nodes (e.g., multiple virtual machines).

[0084] Therefore, the first part of the action performed by the transmission network node 13a can be performed in the first device, and the second part of the action can be performed in the second device; the embodiments disclosed herein are not limited to any particular number of devices capable of performing the actions performed by the transmission network node 13a.

[0085] Therefore, the methods according to the embodiments disclosed herein are suitable for execution by devices residing in a cloud computing environment. Thus, although in Figure 8 A single processing circuit 810 is shown, but the processing circuit 810 can be distributed across multiple devices or nodes.

[0086] Figure 9 A network in the form of an Open RAN 101 (O-RAN) capable of implementing the embodiments is shown. For example, the method can be implemented in one or more network nodes located between O-RU 800 and O-DU 700 in a transport network.

[0087] Referring to O-RAN 101, the role of the non-real-time RAN Intelligent Controller (RIC) 200 is, for example, to provide a service management and orchestration framework to provide services to one or more radio base stations 300 (i.e., RAN sites) referred to as O-eNBs via the O1 interface and to provide high-level control signaling to the near real-time RIC 400 via the A1 interface; such signaling includes, but is not limited to, policy-based guidance, machine learning (ML) model management, and data enrichment. The near real-time RIC 400 performs low-level signaling control over O-RAN compatible network elements (including one or more O-eNBs 300, O-CU-CP 500, O-CU-UP 600, and O-DU 700) via the E2 interface. Additionally, it includes the O-RU 800, connected to the O-DU 700 via the Control, User, and Synchronization (CUS) plane and via the Management (M) plane, and the O-Cloud 900 (i.e., the cloud platform). Therefore, the embodiments described in detail above can be advantageously implemented in a transport network node located between O-RU 800 and O-DU 700 in the transport network.

[0088] The aspects of this disclosure have been described above with reference to several embodiments and examples thereof. However, as will be readily understood by those skilled in the art, other embodiments besides those disclosed above may also be within the scope of the invention as defined by the appended claims.

[0089] Therefore, 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 illustrative purposes and not restrictive, and the true scope and spirit are indicated by the appended claims.

Claims

1. A method for a transmission network node (13a) to perform load balancing in a transmission network (10), comprising: Receive (S101) a data service flow to be sent from the source radio access network RAN ​​node (11a) to the destination RAN node (12a) connected to the transmission network (10) via the transmission network (10); Identify (S102) multiple data service sub-flows that form a data service flow from the source RAN node (11a) to the destination RAN node (12a); (S103) Determine one or more routing paths, through which the identified data service sub-stream can be sent to the next-hop node (13b, 13g) in the transmission network (10); and if multiple possible routing paths exist: Then, the identified data service sub-streams in the data service stream are sent alternately (S104) via different determined routing paths to achieve load balancing in the transmission network (10).

2. The method according to claim 1, wherein in the case of control plane service, the sub-stream is identified by identifying the Real-time Control Data Identifier (RTC_ID) from the message header of the data frame; and in the case of user data service, the sub-stream is identified by identifying the Physical Channel Identifier (PC_ID) from the message header of the data frame.

3. The method according to any one of the preceding claims, wherein the source RAN node is identified by identifying the source Media Access Control (MAC) address from the message header of the data frame (11a), and the destination RAN node is identified by identifying the destination MAC address from the message header of the data frame (12a).

4. The method according to any one of claims 2 or 3, wherein the message header is an Evolved Common Public Radio Interface (eCPRI) protocol message header.

5. The method according to any one of the preceding claims, identifying the source RAN node (11a) and the destination RAN node (12a) from a destination address, wherein the destination address identifies the destination RAN node (12a) and the source RAN node as a pair of RAN nodes through which the data service flow is transmitted.

6. The method according to any one of the preceding claims, wherein the transmission network node (13a) is a transmission network edge node.

7. The method according to any one of the preceding claims, wherein the receiving (S101) further comprises: The output of the hash function is received, in which the source RAN node (11a) has performed a hash operation on at least the identifier and destination RAN node address of the data service sub-stream (S100); wherein, multiple data service sub-streams are identified (S102) in the following manner: Identify the multiple data service sub-streams from the received hash function output.

8. The method according to claim 7, wherein the source RAN node (11a) also includes the source RAN node address in the hash.

9. The method according to any one of the preceding claims, wherein, Multiple data service sub-streams are identified in the following way (S102): The identifier of the data service sub-flow is derived from the customer virtual LAN identifier (C-VID), wherein the identifier of the data service sub-flow has been included (S100a) in the C-VID by the source RAN node (11a).

10. The method according to any one of the preceding claims, identifying the source RAN node (11a) from a unique source RAN node identifier, the unique source RAN node identifier having been encoded by the source RAN node (11a) into the identifier of the data service subflow.

11. A computer program (812) comprising computer-executable instructions, which, when executed on a processing unit (811) included in a transmission network node (13a), cause the transmission network node (13a) to perform the steps according to any one of claims 1 to 10.

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

13. A transmission network node (13a) configured to perform load balancing in a transmission network (10), the transmission network node (13a) including a processing unit (811) and a memory (813) containing instructions (812) executed by the processing unit (811), thereby enabling the transmission network node (13a) to operate to: Receive (S101) a data service flow to be sent from the source radio access network RAN ​​node (11a) to the destination RAN node (12a) connected to the transmission network (10) via the transmission network (10); Identify (S102) multiple data service sub-flows that form a data service flow from the source RAN node (11a) to the destination RAN node (12a); (S103) Determine one or more routing paths, through which the identified data service sub-stream can be sent to the next-hop node (13b, 13g) in the transmission network (10); and if multiple possible routing paths exist: Then, the identified data service sub-streams in the data service stream are sent alternately (S104) via different determined routing paths to achieve load balancing in the transmission network (10).

14. The transmission network node (13a) according to claim 13 is operable to: identify a sub-stream by identifying the Real-time Control Data Identifier (RTC_ID) from the message header of a data frame in the case of control plane services; and identify a sub-stream by identifying the Physical Channel Identifier (PC_ID) from the message header of a data frame in the case of user data services.

15. The transmission network node (13a) according to claim 13 or 14 is operable to: identify the source RAN node (11a) by identifying the source Media Access Control (MAC) address from the message header of the data frame, and identify the destination RAN node (12a) by identifying the destination MAC address from the message header of the data frame.

16. The transmission network node (13a) according to claim 14 or 15, wherein the message header is an Evolved Universal Public Radio Interface (eCPRI) protocol message header.

17. The transport network node (13a) according to any one of claims 13 to 16 is operable to: identify the source RAN node (11a) and the destination RAN node (12a) from a destination address, the destination address identifying the destination RAN node (12a) and the source RAN node as a pair of RAN nodes through which the data service flow is transmitted.

18. The transmission network node (13a) according to any one of claims 13 to 17, wherein the transmission network node (13A) is a transmission network edge node.

19. The transmission network node (13a) according to any one of claims 13 to 18, when receiving (S101) the data service stream, is further capable of operating to: The output of the hash function is received, in which the source RAN node (11a) has performed a hash operation on at least the identifier of the data service sub-stream and the address of the destination RAN node (S100); wherein, Multiple data service sub-streams are identified in the following way (S102): Identify the multiple data service sub-streams from the received hash function output.

20. The transmission network node (13a) according to any one of claims 13 to 19, wherein the source RAN node (11a) also includes the source RAN node address in the hash.

21. The transmission network node (13a) according to any one of claims 13 to 20, when identifying (S102) multiple data service sub-streams, is also capable of operating to: The identifiers for the data service sub-streams are derived from the customer's Virtual LAN ID (C-VID), where... The identifier of the data service sub-flow has been included (S100a) in the C-VID by the source RAN node (11a).

22. The transport network node (13a) according to any one of claims 13 to 21 is operable to: identify the source RAN node (11a) from a unique source RAN node identifier, the unique source RAN node identifier having been encoded by the source RAN node (11a) into the identifier of the data service subflow.

Images