Network nodes and methods for handling transport resources in a wireless communication network

Abstract

Network nodes and method for handling transport resources in a wireless communication network (400) are provided A first RAN node (410) serves one or more second RAN nodes (421, 422). The first RAN node (410) sends a request to one 5 or more second RAN nodes (421, 422) for requesting transport related information from the one or more second RAN nodes (421, 422), wherein the transport related information comprises a set of transport network metrics related to their transport resource utilization. The first RAN node (410) sends a request to a third transport network node (430) for requesting transport related information from the third transport 10 network node (430), wherein the transport related information comprises a set of transport network metrics related to transport resource capacity. The first RAN node (410) determining or obtaining indication whether the transport resource utilization of the one or more second RAN nodes (421, 422) and / or the transport resource capacity provisioned by the third transport network node (430) need to be adjusted based on 15 the reported transport resource utilization and provisioned transport resource capacity.

Description

[0001] NETWORK NODES AND METHODS FOR HANDLING TRANSPORT RESOURCES IN A

[0002] WIRELESS COMMUNICATION NETWORK

[0003] TECHNICAL FIELD

[0004] Embodiments herein relate to network nodes and methods therein. In particular, they relate to handling transport resources for one or more radio access network nodes in a wireless communication network.

[0005] BACKGROUND

[0006] In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, and / or user equipment (UE), communicate via a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a “NodeB” or “eNodeB” or “eNB” or “gNB”. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless communication device within a range of the radio network node.

[0007] A Universal Mobile Telecommunications System (UMTS) is a third generation (3G) telecommunication network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM). Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network or Long Term Evolution (LTE) have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (5G) New Radio (NR) network, Next Generation (NG) and upcoming releases.

[0008] For 5G or NG RAN, dynamic RAN service allocation in mobility scenarios is of interest for many Communication Service Providers (CSPs). Whether users are individuals with personal devices on the move or businesses using them in industrial settings, what users want from 5G networks can change quickly and vary throughout the day, e.g. from listening to a podcast during a morning dog-walk to plotting routes for deliveries, traffic steering helps ensure that they get the experience they desire by making the most of spectrum assets. The theorem is that 5G requires advanced traffic steering across different cell sites in order to respond to the changing of UE demand and their relevant mobility. Any change in the UE demand requires the availability of an equivalent or better cell set in order to manage the handover of the UE:s and this reflects also the usage of its relevant Transport Network resources. A 5G transport network (TN) connects 5G RAN and core network. To provide ultra-high bandwidth, ultra-low latency, and flexible and intelligent connection services necessary in 5G application scenarios, the 5G transport network uses a new network architecture and key technologies. A Transport Network consists of various network elements such as routers, switches, optical transmission equipment, and multiplexers / demultiplexers. These elements facilitate the transmission and routing of data packets or signals across the network. The structure of a 5G Transport Network includes base stations for wireless connectivity, fronthaul and midhaul networks for high-speed data transport, optical fiber infrastructure for connectivity, core network for data routing and management, and packet switching technology for efficient data handling. This structure enables the delivery of high-speed, low-latency, and reliable connectivity in 5G networks to support a wide range of applications and services. The 5G / NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG- RAN architecture, i.e. the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL. For each NG-RAN interface, NG, Xn, F1 , the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport, signaling transport.

[0009] The diversity of cells with different capacities, coverage, and configurations, together with even more diverse devices with various capabilities and services used, adds a lot of complexity to optimizing network performance and spectrum utilization. Traffic steering has the potential to address these complexities while delivering on expected service requirements and user experiences.

[0010] The main drivers for RAN optimization are:

[0011] • Diversity of frequency bands: 5G is designed to work in different frequency ranges. As the number of frequencies increases, so does the importance of placing UEs in the best cells. Combined with carrier aggregation (CA), this means CSPs must consider multiple cells, or sets of cells, when selecting the most adequate cell set for each UE.

[0012] • Diversity of 5G services and UEs: Some 5G services will require massive capacity and throughput, while others will be more dependent on latency and low-energy consumption in the UE. The UE may also be tailored to different types of use cases such as smartphones, simple sensors, augmented reality (AR) headsets, and fixed-wireless access (FWA) equipment, where different levels of feature support are required.

[0013] • Carrier Aggregation was included in the first release of the 5G standard, making it possible to configure a PCell for UEs and then add one or more SCell(s) to increase their downlink (DL) or uplink (UL) throughput. The total UE throughput with CA is realized by the combination of the PCell and the SCell(s), instead of individual cells. But the number of combinations of PCell and SCell(s) to be aggregated could be huge and varies for different UEs according to their capabilities. This brings complexity to finding the best UE configuration for each network deployment.

[0014] • Load distribution, if all devices got the same set of PCell and SCell(s), those cells would quickly become fully loaded. When networks start adding more cells than what the devices can aggregate, traffic steering needs to consider the load on each cell and distribute the selected cells among the devices, otherwise each user will get completely different experiences. This increases the utilization of each cell while improving the throughput for each device.

[0015] Focus have been put on two critical areas for RAN performance optimization relevant to “Mobile Backhaul (MBH)” and “Fronthaul” domains as they can heavily impact the overall RAN performances and its relevant optimization strategies. MBH refers to the part of the network that connects the cell sites like base stations or small cells to the core network. It is responsible for transporting data traffic between the cell sites and the core network, enabling communication between mobile devices and the broader telecommunications infrastructure. The fronthaul domain is RAN-near transport domain which refers to the portion of the transport network that is closely integrated with the RAN. This domain encompasses the transport network elements and functionalities that directly support the connectivity between the radio base stations e.g. gNodeBs or small cells and the core network. The fronthaul domain includes a fronthaul network, which connects radio base stations gNodeBs or small cells to the central processing units (CUs) or distributed units (DUs) within the RAN. Fronthaul connectivity is essential for transporting high-speed data traffic between the radio equipment and the processing units. Figure 1 shows an example of a 5G transport network architecture 100. In the transport network architecture 100, a number of RAN nodes, e.g. eMBB, mMTC, radio unit (RU), Centralized Unit (CU), Distributed Units (DU), a number of routers (R), a Data Center (DC), a core network (CN) etc. are operating. A CU may control one or more DUs. A RAN CU may be an implementation of a logical gNB-CU or gNB-CU-CP. A gNB may consist of a gNB-CU and one or more gNB-DU(s). A gNB-CU and a gNB-DU is connected via F1 interface. gNBs can be interconnected through Xn interface. MBH and Fronthaul are relevant to the Xn / X2 / F1 / E1 interfaces, using Internet Protocol (IP) transport networks to interconnect network nodes.

[0016] At current state-of-art, MBH and Fronthaul use the general concepts of Quality of Service (QoS) and network slicing for RAN service differentiation and traffic optimization. The techniques have been developed and standardized by Internet Engineering Task Force (IETF) to address IP networking scenarios. As a result, the Transport Network can differentiate the performances offered by each Transport network slice and therefore provide different bandwidth, latency, availability.

[0017] The introduction of new 5G features increases the demand for more efficiency in the RAN and its RAN-near Transport domain. Failing to coordinate the two domains might result in impacts on network performance, reducing the overall benefits of any traffic engineering strategy.

[0018] The main drivers for RAN Traffic changes are relevant to:

[0019] • Much higher cell capacities e.g. mmW cells, ranging up to 100Gb / s

[0020] • Methods for dynamic allocation and aggregation of cell capacity.

[0021] • Methods for cell load balancing.

[0022] In response to this new Traffic demand, the current RAN Transport paradigm is not sufficient since it is bound to a static and statistical approach, such as:

[0023] • Offer Mobile Backhaul (BH) and Fronthaul (FH) transport services based on the Service Level Objectives (SLO) committed by the Transport Orchestrator.

[0024] • Transport services are supposed to be optimized by Orchestrator or Software Defined Network (SDN) according to the SLO demand agreed with their attachment services, e.g. RAN services in this case.

[0025] • If there’s any change in the RAN demand, the current approach is for RAN network to notify the new SLO to the T ransport Orchestrator to re-arrange the T ransport slices accordingly.

[0026] When RAN implements quasi real-time optimization, such as load balancing or pooling of their RAN Compute resources, the Transport Network risks staying behind and creating bottlenecks for successful deployment of RAN services. For example, Transport Network remains committed to the SLO agreed statically with the RAN Orchestrator, whereas RAN traffic changes can only be accommodated within a predefined statistical variance i.e. the best effort cases. Currently, there are no 3GPP or IETF standards addressing the integration to make Transport network more dynamic adjusting its resources to RAN requirements. The statistical multiplexing approach for Service Orchestration is no longer efficient when one consider high variance of RAN traffic demand driven by dynamic RAN Traffic engineering. If the transport network is dimensioned for an average cell usage, e.g. typically 50% of cell peak load, it would not be ready to introduce new Ultra Reliable Low Latency Communication (URLLC) or other low latency and high throughput services e.g., gaming, or it would result in frequent reduction of the network performances during peak hours. On the other side, dimensioning the transport network for the worst case. e.g. the highest peak traffic, will result in expensive network infrastructure and high operational costs due to the permanent allocation of unused resources and equipment. Such resources might well be used to offer additional services in other coverage areas that share the same transport resources.

[0027] At current state-of-art, the coordination across RAN and Transport domains is typically managed in non-real-time mode, e.g., pre-planning and provisioning the Transport domain, with the alternative to coordinate Radio and Transport domains at Service Orchestration level.

[0028] In case of dynamic changes in the allocated RAN capacity, it should be possible to optimize the Transport capacity accordingly. Mobility Load Balancing is envisaged as one of the use cases where tighter coordination between RAN and Transport is required. It is also noted that transport network is a contributor to the overall latency and resilience of the mobile services and this aspect is particularly important in the case of URLLC services according to 3GPP standard specification. QoS monitoring to assist URLCC service is described in 3GPP standard TS 23.501 v18.0.0, section 5.33.3. URLCC has stringent requirements on the availability and the latency supported by the mobile network and the mobile network conversely relies on one or more underlying Transport network segments. It is envisaged that the monitoring and control of the T ransport segments, e.g., backhaul and core network connections, can provide a significant advantage to optimize the deployment of new services as well as to control and balance traffic on different Transport paths.

[0029] Current state of art approach was an acceptable trade-off for 4G and first generation of 5G services, but it might be a limiting factor for advanced 5G services and 6G evolution.

[0030] SUMMARY

[0031] It is an object of embodiments herein to provide an improved method for handling transport resources in a wireless communication network. According to one aspect of the embodiments herein, the object is achieved by a first RAN node and method therein for handling transport resources for one or more second RAN nodes served by the first RAN node. The first RAN node sends a request to one or more second RAN nodes for requesting transport related information from the one or more second RAN nodes. The transport related information from one or more second RAN nodes comprises a set of transport network metrics related to their transport resource utilization (TRU). The first RAN node further sends a request to a third transport network node for requesting transport related information from the third transport network node. The transport related information from the third transport network node comprises a set of transport network metrics related to transport resource capacity (TRC) provisioned by the third transport network node. The first RAN node determines or obtains indication whether the TRU of the one or more second RAN nodes and / or the TRC provisioned by the third transport network node need to be adjusted based on the reported TRU and provisioned TRC.

[0032] According to some examples, the first RAN node may be implemented as a RAN- CU, or as a transport network node between a RAN-CU or gNB-CU and one or more RAN-DUs or gNB-DUs served by the RAN-CU or gNB-CU. The second RAN node may be a RAN-DU or a gNB-DU served by the RAN-CU or gNB-CU. The third transport network node may be any one of a Transport Controller, a Transport Planning System, a Transport Software Defined Network Controller (T-SDNc), a Transport Service Orchestrator, or any other Transport Traffic Engineering Tool.

[0033] According to some examples, the transport related information may comprise one or more or any combination of the following: a) Downlink, DL, and / or uplink, UL , transport network layer, TNL, Offered Capacity at different granularities; b) DL and / or UL TNL Available Capacity at different granularities; c) DL and / or UL TNL Available Bandwidth at different granularities; d) Latency at different granularities; e) Round trip time at different granularities; f) Packet error rate in downlink and / or uplink and at different granularities; g) Packet drop rate or packet loss in downlink and / or uplink at different granularities; h) Queuing delay in downlink and / or uplink at different granularities; i) Quality of Service (QoS) related information at different granularities. According to one aspect of the embodiments herein, the object is achieved by a second RAN node and method therein for handling transport resources in a wireless communication network. The second RAN node is served by a first RAN node. The second RAN node receives a request from the first RAN node to report transport related information, wherein the transport related information comprises a set of transport network metrics related to transport resource utilization. The second RAN node further sends the requested transport related information to the first RAN node and receives updated values of transport resources from the first RAN node or a third transport network node.

[0034] According to one aspect of the embodiments herein, the object is achieved a third transport network node for handling transport resources in a wireless communication network. The third transport network node receives a message from a first RAN node, wherein the message comprises a request or indication for requesting or indicating whether updating transport resources is needed for one or more second RAN nodes. The third transport network node takes actions to update transport resources for the one or more second RAN nodes based on the message and sends updated values of the transport resources to the first RAN node or to the respective one or more second RAN nodes.

[0035] The solutions according to embodiments herein introduces new functionality, e.g. “RAN Transport Agent (RTA)” and / or “RAN Traffic Engine (RTE)” implemented as a function in one or more existing RAN node, i.e. the first and / or second RAN node, e.g. a RAN DU, a RAN CU, or implemented as a separate node, to perform transport related algorithms for coordination between Radio and Transport domain. The usage of transport resources as perceived by a RAN node, i.e. the second RAN node e.g. BBU, CU, DU, is monitored by its RTA function. The RTA function reports the monitored usage of transport resource to a RTE function implemented in a RAN CU. Based on the received information concerning the transport resource usage, the RTE function determines or obtains an indication that new / updated transport resources are needed and requests new / updated transported resources to the third transport network node e.g. a Transport SDN Controller (T-SDNc). The T-SDNc determines new / updated transport resources e.g. TNL Offered Capacity or other TNL related configuration parameter(s) for one or more RAN DUs. In this way, dynamic remapping of the RAN network slices over the Transport network slices is realized, either by sending the new mapping, i.e. the new / updated transport resources to the one or more RAN Dlls directly or sending the new mapping to the RAN CU which in turns sends the new mapping to the RAN DU.

[0036] Embodiments herein exploit new RAN functional improvements already proposed for 3GPP R19 standardization and provide some advantages for examples:

[0037] • Close-loop transport resource optimization with feedback from TNL metrics.

[0038] • Better transport resource optimization, adaptive allocation of transport network slices.

[0039] • Total cost of ownership (TCO) improvement by better use of bandwidth and transport network.

[0040] • Improved performance of the e2e 5G services with guaranteed QoS.

[0041] • Leverages on existing 3GPP protocol stack, self-confined and RAN transparent in transport nodes.

[0042] • Smooth integration of radio and transport interaction, supporting different functional splits.

[0043] Therefore embodiments herein provide improved methods and apparatus for handling transport resources in wireless communication networks.

[0044] BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Examples of embodiments herein are described in more detail with reference to attached drawings in which:

[0046] Figure 1 is a schematic block diagram illustrating an example of a communication system;

[0047] Figure 2 is a schematic block diagram illustrating new feature or function blocks introduced in a communication system for handling transport resources according to embodiments herein;

[0048] Figure 3 is a schematic block diagram illustrating another example implementation of new feature or function blocks according to embodiments herein;

[0049] Figure 4 is a schematic block diagram illustrating a communication network in which new feature or function blocks may be implemented in existing network nodes according to embodiments herein;

[0050] Figure 5 is a signal flow chart illustrating an example signal flow between a first RAN node, a second RAN node and a third transport network node according to embodiments herein; Figure 6 is a flow chart illustrating an example embodiment of a method performed in a first RAN node according to embodiments herein;

[0051] Figure 7 is a flow chart illustrating an example embodiment of a method performed in a second RAN node according to embodiments herein;

[0052] Figure 8 is a flow chart illustrating an example embodiment of a method performed in a third transport network node according to embodiments herein;

[0053] Figure 9 is a schematic block diagram illustrating an example embodiment of cloud implementation according to embodiments herein;

[0054] Figure 10 is a schematic block diagram illustrating an example embodiment of a first RAN node according to embodiments herein;

[0055] Figure 11 is a schematic block diagram illustrating an example embodiment of a second RAN node according to embodiments herein; and

[0056] Figure 12 is a schematic block diagram illustrating an example embodiment of a third transport network node according to embodiments herein.

[0057] DETAILED DESCRIPTION

[0058] In this disclosure, the term “Network Node” may sometimes referred to as a “NN”. “Transport Network Layer” (TNL) and “Transport Network” may be used interchangeably.

[0059] “TNL related information” may comprise “TNL load metric”, “TNL Offered Capacity”, “TNL Available Capacity” and “TNL related parameters” such as delay, packet loss, jitter etc.

[0060] A TNL “Offered” resource is to be intended as the maximum (or a target) value for a certain attribute / parameter associated to TNL, e.g., the “TNL Offered Capacity”, or the TNL Committed information rate for the TNL slice, or the maximum bandwidth that can be exploited over a certain TN connection / link.

[0061] A TNL “Available” resource is to be intended a value, either in absolute numbers e.g., in kbps, Mbps, or substantially equivalent units, or in percentage relative to the “Offered” maximum or a target value for a certain attribute / parameter associated to TNL. For example, a TNL Available Capacity can be a percentage of the TNL Offered Capacity in kbps.

[0062] A network node may be a RAN node, an NG-RAN node, an LTE node, a 6G node, a function in a 6G node, a gNB, eNB, en-gNB, ng-eNB, gNB-DU, gNB-CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, lAB-node, lAB-donor DU, lAB-donor- CU, IAB-DU, IAB-MT, O-CU, O-CU-CP, O-CU-UP, O-DU, O-RU, O-eNB, a Non-Real Time RAN Intelligent Controller (Non-RT RIC), a Real-Time RAN Intelligent Controller (RT-RIC), a Core Network node, a vDU, a vCU, a router, a Transport Network Layer (TNL) resource controller, a Transport Software-Defined Networking (T-SDN) controller.

[0063] Embodiments herein provides a method to map the RAN traffic demand to the appropriate Transport network resources impacted by 5G steering. The proposed solutions enable a dynamic remapping of the RAN network slices to the Transport network slices offered by the Transport orchestrator.

[0064] The limitations or problems in the TNL resources may be:

[0065] - the UL / DL bandwidth allocated / available for a certain transport user plan path is fully occupied or overloaded;

[0066] - the UL / DL bandwidth allocated / available for a certain transport user plan path is above or below a certain threshold;

[0067] - the UL / DL bandwidth allocated / available for a certain Class of Service or group of Class of Services is overloaded;

[0068] - the UL / DL bandwidth allocated / available for a certain Class of Service or group of Class of Services is above or below a certain threshold;

[0069] - the Round Trip Time (RTT), as determined / measured at one of the first / second / third / fourth / fifth network node for a certain transport user plan path exceeds or is equal to a certain threshold;

[0070] - the Round Trip Time (RTT), as determined / measured at one of the first / second / third / fourth / fifth network node for a certain Class of Service or group of Class of Services exceeds or is equal to a certain threshold;

[0071] - the UL / DL latency, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain transport user plan path exceeds or is equal to a certain threshold;

[0072] - the UL / DL latency, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain Class of Service or group of Class of Services exceeds or is equal to a certain threshold;

[0073] - the UL / DL packet loss, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain transport user plan path exceeds or is equal to a certain threshold;

[0074] - the UL / DL packet loss, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain Class of Service or group of Class of Services exceeds or is equal to a certain threshold; - the LIL / DL packet error rate, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain transport user plan path exceeds or is equal to a certain threshold;

[0075] - the LIL / DL packet error rate, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain Class of Service or group of Class of Services exceeds or is equal to a certain threshold;

[0076] - the LIL / DL queuing delay, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain transport user plan path exceeds or is equal to a certain threshold;

[0077] - the LIL / DL queuing delay, as determined / measured at one of the first / second / third / fourth / fifth network node for a certain Class of Service or group of Class of Services exceeds or is equal to a certain threshold.

[0078] Embodiments herein introduce new functionality RAN Transport Agent (RTA) and / or RAN Traffic Engine (RTE) to perform transport resource related monitoring and algorithms for coordination transport resource between Radio and Transport domain. The usage of transport resources as perceived by a RAN node, e.g. BBU, CU, DU, is monitored by a RAN Transport Agent (RTA) function. The RTA reports the monitored usage of transport resource to the RAN Traffic Engine (RTE) function. Please notice that the RTA and RTE can be referred to as one function.

[0079] An RTA can be implemented as a function in an existing RAN node e.g. in an RAN DU and / or an RAN CU, or as a separate node.

[0080] According to some embodiments herein, RTA and RTE functions may deployed on a multiplicity of RAN Distributed Units (DU) and / or RAN Central Units (CU) to perform Transport related algorithms. Figure 2 shows an example implementation of RTA and RTE, where RTA and RTE may be implemented in one or more existing CUs, e.g. CU1, CU2, and RTA may be implemented in one or more existing DUs, e.g. DU1 , DU2, DU3, DU4.

[0081] Figure 3 shows another implementation of RTA and RTE, where an RTA is implemented as a transport network node supporting snooping functionality of the radio application protocol e.g., F1AP to monitor in-transit TNL parameters as intermediate CU- DU link monitoring point. One or more RTA and RTE may be implemented in one or more existing CUs, e.g. CU1 , CU2. One or more RTA may be implemented in one or more existing DUs, e.g. DU1 , DU2, DU3, DU4. Figure 4 illustrates a simplified overview of a communication network 400, wherein the new features or functions RTA / RTE for handling transport resources are implemented in e.g. one or more RAN nodes e.g. RAN CUs and / or RAN Dlls. The communication network 400 comprises a number of nodes, e.g. one or more base stations or remote radio units (RRU) RRU1 , RRU2, deployed at various locations to provide wireless communication coverage and connect user devices UE to the network, one or more RAN nodes, e.g. a Central Unit CU 410, one or more Distribute Units DU 421, DU 422 and a transport SDN controller T-SDNc 430 for orchestrating and managing transport network resources. The Central Unit CU 410 controls one or more DUs, e.g. DU 421, DU 422 through transport network TN. The communication network 400 also comprises other function nodes or network nodes which are not shown.

[0082] According to some example embodiments, the RTA in an RAN DU monitors QoS of the TNL and reports related metrics and / or TNL parameters and / or TNL performances to the RTE function hosted in an RAN CU. The RTE collects from T-SDNc the provisioned capacity relevant to the CU-DU links and compares with the offered and available capacity reported by RTAs in respective RAN DUs. According to 3GPP standards, the RAN DU and the CU exchange TNL parameters over F1 interface. TNL parameters include offered or configured capacity and available e.g. usage or free, capacity. Offered capacity is the capacity allocated to the DU and CU for their TNL. Provisioned capacity is the capacity allocated by the Transport layer. In ideal conditions, the provisioned capacity should match offered capacity and the available capacity should provide enough buffer for traffic peaks.

[0083] Based on the received information concerning the TNL resource usage, the RTE function determines or obtains an indication that new or updated TNL resources are needed and requests the new or updated TNL resources to the Transport SDN Controller T-SDNc.

[0084] The T-SDNc determines new or updated TNL Offered Capacity or other TNL related configuration parameter(s).

[0085] The dynamic remapping of the RAN network slices over the Transport network slices is realized by setting the new or updated TNL Offered Capacity or other TNL related configuration parameter(s)) for one or more RAN Distributed Unit(s). The setting can be performed indirectly, i.e. , the T-SDNc sends the new mapping to the RAN CU, which in turns sends the mapping to one or more RAN DUs, or directly, i.e., the T-SDNc sends the new mapping directly to one or more RAN DUs. The RTE, responsive to the detection of discrepancy among provisioned, offered and available transport capacity, initiates actions towards CU or T-SDNc including but not limited to:

[0086] • RAN CU to modify the offered TNL capacity from / to one or more DU(s), responsive to a change in the Transport available capacity from / to the one or more DU(s).

[0087] • T-SDNc to initiate a request to change one or more CU-DU transport link capacity. For example, RTE of RAN CU may decide to reduce the offered capacity or ask T-SDNc to increase or reduce the provisioned capacity.

[0088] In an example of implementation, the solution may use Transport network layer (TNL) information elements calculated and communicated over the standardized interfaces, such as the 3GPP F1 and / or Xn interfaces respectively according to TS 38.473 and TS 38.423, and / or defined as a proprietary extensions to the 3GPP standards.

[0089] According to some embodiments herein, new RTA and RTE features or functions may be proposed to implement in a RAN network node based on 3GPP standard TS 38.300 whereas a CU can control a multitude of DUs and whereas the RAN CU can be an implementation of a logical gNB-CU or gNB-CU-CP) as defined in 3GPP standard TS 38.300.

[0090] Figure 5 shows an example signal flow chart between the network nodes RAN CU, RAN DU1 , RAN DU2 and T-SDNc for handling transport resources in the communication network 400. The signal flow comprises the following steps.

[0091] Step 510 / 511: The RTA / RTE of the RAN CU sends a request message to one or more RAN DUs to request the RTA of the one or more DUs, e.g. DU1, DU2, to provide TNL related information concerning the usage of certain TNL resources, e.g., TNL Available Capacity. This step may be repeated for all the DUs served by the CU. This step may be realized according to existing 3GPP standard, for instance by means of a RESOURCE STATUS REQUEST F1AP message.

[0092] Step 520 / 521: The RTA in the one or more DUs reports to the RTA of the CU the requested TNL related information. This step may be realized according to existing 3GPP standard, for instance by means of a RESOURCE STATUS UPDATE F1AP message.

[0093] Step 530: The RTA of the CU may send to the RTE of the CU the TNL related information obtained from the RTA of the DUs, if the RTA and RTE are implemented as two separate function blocks in the CU. If the RTA and RTE are implemented as one function block in the CU, the RTE or RTA of the CU, based at least in part on the received TNL related information, determines itself or obtains from another entity / function within / outside the CU that new / updated TNL resources e.g., an updated value of TNL Offered Capacity are needed for one or more DUs.

[0094] Step 540: The RTE or RTA of the CU sends a message to the T-SDNc, the message comprising at least one of:

[0095] - a request to increase TNL resources pertaining to a DU or all DUs.

[0096] - a request to reallocate TNL resources pertaining to a DU to another DU.

[0097] - a request to reallocate TNL resources pertaining to a certain DU to another specific DU.

[0098] - an indication that TNL resources allocated pertaining to a certain DU are not sufficient.

[0099] - an indication that TNL Offered Capacity pertaining to a certain DU is not sufficient.

[0100] - an indication that TNL Available Capacity pertaining to a certain DU is low or too low, or lower than a threshold.

[0101] - an indication that TNL resources pertaining to a certain DU is sufficient.

[0102] - an indication that TNL Offered Capacity pertaining to a certain DU is sufficient.

[0103] - an indication that TNL Available Capacity pertaining to a certain DU is high or higher than a threshold.

[0104] - an indication that TNL Available Capacity pertaining to a certain DU is critical.

[0105] - an indication that a certain difference in TNL resources pertaining to a certain DU e.g., a difference between TNL Offered Capacity and TNL Available Capacity, is too low, either in absolute values of in percentage.

[0106] Any of the above information can be requested or reported for a certain granularity or at different granularities, for instance, per Class of Service, or per cell etc.

[0107] The same message as in step 540, or a separate message, may be sent from the RTE of the CU to the T-SDNc to report TNL related information, as received from the RTA of the one or more DUs, or in some aggregated format e.g., the maximum, or the minimum, or the average of TNL Available Capacity over a certain time interval.

[0108] Step 550: According to one example, the T-SDNc may send to the RTE / RTA of the CU the new / updated values of TNL related information e.g., the new values of TNL Offered capacity to be applied to the one or more DUs. This step may in alternative be executed between the T-SDNc and the RTA of the one or more DUs, in which case the Steps 551 and 552 that follows are not executed. Step 551 / 552: The RTA of the Central Unit sends to the RTA of the one or more DUs the new / updated values of TNL related information received from the T-SDNc in Step 550.

[0109] Alternatively, the T-SDNc may send the new / updated values of TNL related information e.g., the new values of TNL Offered capacity to be applied to the one or more DUs, to the respective DUs.

[0110] According to embodiments herein, RTA / RTE may be implemented generally in a first RAN node, e.g. RAN CU 410, for handling transport or TNL resources for one or more second RAN nodes, e.g. DU 421 , DU 422, in a communication network e.g. the communication network 400 as shown in Figure 4.

[0111] A method performed by a first RAN node 410 in a wireless communication network 400 for handling transport resources for one or more second RAN nodes 421, 422 served by the first RAN node 410 will be described with reference to Figure 6. The method comprises the following actions which may be performed in any suitable order and some actions may be optional.

[0112] Action 610

[0113] The first RAN node 410 sends a request to one or more second RAN nodes 421, 422 for requesting transport or TNL related information from the one or more second RAN nodes 421 , 422. The transport / TNL related information comprises a set of transport network metrics related to their transport resource utilization (TRU).

[0114] The request sent to one or more second RAN nodes 421 ,422 for reporting transport related information may further comprise one or more of the following: a) request to provide a certain aggregation level for the transport related information, e.g. average, maximum, minimum values over a certain time interval, and / or average, maximum, minimum values for certain Class of Service(s) etc.; b) request to provide a specific transport related information, e.g., DL / UL TNL Offered Capacity, DL / UL TNL Available Bandwidth, latency, etc.; c) request to provide a specific transport related information with a certain granularity, e.g., DL / UL TNL Offered Capacity, DL / UL TNL Available Bandwidth, latency, etc. per Class of Service.

[0115] For example, RAN CU and DU may calculate their respective offered / available capacity for UL and DL. The RAN CU already knows UL TNL data and request the RTA of DU to provide them from DU side. In an alternative embodiment the data exchange may be requested via the CU / DU management plane.

[0116] Action 620

[0117] The first RAN node 410 sends a request to a third transport network node, e.g. T- SDNc 430, for requesting transport / TNL related information from the third transport network node 430. The transport / TNL related information comprises a set of transport network metrics related to transport resource capacity (TRC).

[0118] The transport / TNL related information is information related to transport network resource utilization, characteristics, performance. The transport / TNL related information may comprise one or more or any combination of the following: a) DL and / or UL transport network layer (TNL) Offered Capacity at different granularities; b) DL and / or UL TNL Available Capacity at different granularities; c) DL and / or UL TNL Available Bandwidth at different granularities; d) Latency at different granularities; e) Round trip time at different granularities; f) Packet error rate in downlink and / or uplink and at different granularities; g) Packet drop rate or packet loss in downlink and / or uplink at different granularities; h) Queuing delay in downlink and / or uplink at different granularities. The queuing delay indicates the amount of time a traffic packet resides into the queue of any of the nodes involved in traffic transport; i) Quality of Service (QoS) related information at different granularities.

[0119] A granularity of the transport related information requested or reported may be any one or a combination of the following: a) per network node, b) per Class of Service, c) per group of Class of Services: a group of Class of Services is a set of one or more Class of Services for which transport network reporting can be achieved, wherein the set is determined based on common characteristics of the individual Class of Services. Common characteristics can be one or more of: . a certain value e.g., a maximum or range of values for delay I packet loss I jitter that the traffic carried over the Class of Services in the group of Class of Services can tolerate;

[0120] . a certain value e.g., a minimum guaranteed bit rate for the Class of Services in the group of Class of Services need;

[0121] . a set of services / communication type whose traffic is carried over transport resources associated to the Class of Services e.g. URLLC type of communication, or Time Sensitive Network type of communication. d) per cell, e) per network slice, e.g., per S-NSSAI, f) per type of spectrum, e.g. licensed or unlicensed / shared spectrum, g) per Radio Access Technology, h) per reference signal beam; i) per QoS flow per user equipment (UE); j) per UE; k) per General Packet Radio Service Tunneling Protocol in User Plane (GTP- U) path.

[0122] The values of the set of transport network metrics may be reported as any one or a combination of the following:

[0123] • maximum / minimum / average values of a transport network metric;

[0124] • distribution values of a transport network metric;

[0125] • an offset value compared to a reference or threshold value for a transport network metric;

[0126] • a percentage of the values collected for a transport network metric during a time period which are fulfilled a certain criterion, e.g. RTT, DL / UL packet error rate, DL / UL packet loss, DL / UL queuing delay are within / above / below a reference / threshold, or between a first reference / threshold and a second reference / threshold;

[0127] • a percentage of users for which the values collected for a transport network metric during a time period are fulfilled a certain criterion, e.g. RTT, DL / UL packet error rate, DL / UL packet loss, DL / UL queuing delay are within / above / below a reference / threshold, or between a first reference / threshold and a second reference / threshold. For examples, for latency, the use of a certain granularity may be combined with the options listed below:

[0128] In one option, the maximum / minimum / average value of experienced latency is reported for a certain network node e.g. a gNB-Dll or a certain cell, or a certain Class of Service.

[0129] In another option, a distribution of values of experienced latency is reported for a certain network node e.g. a gNB-Dll or a certain cell, or a certain Class of Service.

[0130] In another option, the maximum / minimum / average value of experienced latency is reported for all the possible / requested / available Class of Services.

[0131] In another option, only the maximum / minimum / average value of latency for one Class of Service I network node I cell is reported, e.g., the maximum / minimum / average of the latencies experienced in a given reporting period for all the requested Class of Services I network nodes I cells.

[0132] In another option, one or more latency values is / are indicated as difference or delta compared to a reference for a given Class of Service I network node I cell.

[0133] In another option, the latency per Class of Service I network node I cell is expressed as a percentage e.g., from 0 to 100, indicating the percentage of users whose packets are associated to a certain Class of Service I network node I cell and whose transmissions were delayed by a time lower than or equal to or alternatively above a reference. The reference can be a value of Packet Delay Budget (PDB) associated with the Class of Service I network node I cell e.g., the value of the maximum PDB of the PDB values of all the users / services whose traffic is carried by TNL resources of a certain Class of Service I network node I cell.

[0134] In another option, the latency is expressed as a percentage e.g., from 0 to 100, indicating the percentage of packets and experiencing a latency or delay higher than or lower than, or within a reference, where the reference may be a value as a PDB.

[0135] In another option, the latency per Class of Service I network node I cell is expressed as a percentage e.g., from 0 to 100, indicating the percentage of packets associated to a certain Class of Service I network node I cell and experiencing a delay within a first reference I threshold and a second reference I threshold e.g., within a lower bound and an upper bound.

[0136] In another option, the latency per Class of Service I network node I cell is expressed as a percentage e.g., from 0 to 100, indicating the percentage of users whose packets are delayed by a certain offset compared to a reference, where the reference can be a value as a PDB associated with the Class of Service I network node I cell, or a value applied to all Classes of Service / network nodes / cells.

[0137] The same options above indicated for TNL related information concerning the latency may also apply for other types of TNL related information, such as Round-Trip- Time, Packet error rate in downlink and uplink, Packet Loss in downlink and uplink, queuing delay in downlink and uplink etc.

[0138] For another example, the TNL related information may comprise information related to QoS monitoring at different granularities, such as per QoS flow per UE, per UE, per GTP-U path.

[0139] Non-limiting examples of such TNL related information may be:

[0140] - UL Delay DU Result e.g., as defined in TS 38.425 v17.2.0, clause 5.5.3.48 or alike.

[0141] - DL Delay DU Result e.g., as defined in TS 38.425 v17.2.0, clause 5.5.3.49 or alike.

[0142] - DL Delay Result e.g., as defined in TS 38.415 v17.0.0, clause 5.5.3.14 or alike.

[0143] - UL Delay Result e.g., as defined in TS 38.415 v17.0.0, clause 5.5.3.16 or alike.

[0144] - N3 / N9 Delay Result e.g., as defined in TS 38.415 v17.0.0, clause 5.5.3.21 or alike.

[0145] Action 621

[0146] This action is optional. The first RAN node 410 may send the transport related information as received from the one or more second RAN nodes 421, 422 or in an aggregated format to the third transport network node 430 or another network node or entity or function within or outside the first RAN node 410. Then the third transport network node 430 or another network node or entity or function within or outside the first RAN node 410 may determine whether the TRC and / or TRU needs to be adjusted by comparing the reported TRU and provisioned TRC and send an indication to the first RAN node 410.

[0147] Action 630

[0148] The first RAN node 410 determines, or obtains indication from the third transport network node 430 or another network node or entity or function within or outside the first RAN node 410, whether the TRU of the one or more second RAN nodes 421, 422 and / or the TRC provisioned by the third transport network node 430 need to be adjusted based on the reported TRU and provisioned TRC.

[0149] The first RAN node 410 may determine whether the TRC and / or TRU needs to be adjusted by comparing the reported TRU and provisioned TRC. Action 640

[0150] When the TRC and / or TRU needs to be adjusted, the first RAN node 410 sends a message to the third transport network node 430 for adjusting TRU for the one or more second RAN nodes 421 , 422 and / or TRC provisioned by the third transport network node 430.

[0151] The message for adjusting TRU and / or TRC may comprises one or more of the following: a) a request to increase TRC pertaining to the first RAN node 410 and the one or more second RAN nodes 421 , 422; b) a request to reallocate transport network resources pertaining to a certain second RAN node to another second RAN node, e.g. from RAN 421 to another RAN; c) a request to reallocate transport network resources pertaining to a certain second RAN node to another specific second RAN node, e,g, from RAN 421 to RAN 422; d) an indication that TRC pertaining to a certain second RAN node is not sufficient; e) an indication that TRC pertaining to a certain second RAN node is sufficient; f) an indication that a certain difference between transport network resources pertaining to a certain second RAN node is too low, either in absolute values or in percentage; g) an indication that DL and / or UL TNL Offered Capacity pertaining to a certain second RAN node is not sufficient; h) an indication that DL and / or UL TNL Available Capacity pertaining to a certain second RAN node is low, or too low, or lower than a threshold; i) an indication that DL and / or UL TNL Offered Capacity pertaining to a certain second RAN node is sufficient; j) an indication that DL and / or UL TNL Available Capacity pertaining to a certain second RAN node is high, or higher than a threshold; k) an indication that DL and / or UL TNL Available Capacity pertaining to a certain second RAN node is critical. After the first RAN node 410 sends a message to the third transport network node 430 for adjusting TRU and / or TRC in Action 640, the method may further comprise the following actions:

[0152] Action 650

[0153] The first RAN node 410 may receive updated values of transport resources from the third transport network node 430.

[0154] Action 660

[0155] The first RAN node 410 may send the updated values of transport resources to the one or more second RAN nodes 421 , 422.

[0156] Alternatively, the third transport network node 430 may send the updated values of transport resources directly to the one or more second RAN nodes 421, 422.

[0157] According to some embodiments, the RTA of the Distributed Unit, before sending to the RTA of the Distributed Central Unit the TNL related information, may send to the RTA of the Central Unit one or more of the following by pre-configuring or by a request from the RTA of the Central Unit:

[0158] - indications of capability, indicating whether it can provide TNL related information.

[0159] - indications of capability, indicating whether it can provide specific TNL related information.

[0160] - indications of capability, indicating whether it can provide specific TNL related information with a certain granularity e.g., per Class of Service.

[0161] - indications indicating whether it can provide certain aggregation level for TNL related information e.g., average, maximum, minimum.

[0162] - indications of one of more TNL related information that the RTA in the Distributed Unit can offer to the RTA of the Central Unit.

[0163] Therefore according to some embodiments herein, the method may further comprise the following actions, which may be performed before Action 610:

[0164] Action 601

[0165] The first RAN node 410 may send one or more messages to the one or more second RAN nodes 421 , 422 to request one or more of the following information: a) capability of reporting transport related information; b) capability of reporting a specific transport related information; c) capability of reporting a specific transport related information with a certain granularity; d) capability of reporting certain aggregation level for the transport related information; e) indications of one or more transport related information that the second RAN node can offer or report.

[0166] Action 602

[0167] The first RAN node 410 may receive one or messages from the one or more second RAN nodes 421, 422, wherein the one or more messages comprises one or more indications indicating the requested information listed above.

[0168] A method performed by a second RAN node 421, 422 in a wireless communication network 400 for handling transport resources will be described with reference to Figure 7. The second RAN node 421, 422 is served by a first RAN node 410. The method comprises the following actions which may be performed in any suitable order and some actions may be optional.

[0169] Action 710

[0170] The second RAN node 421, 422 receives a request from the first RAN node 410 to report transport related information, wherein the transport related information comprises a set of transport network metrics related to transport resource utilization.

[0171] Action 720

[0172] The second RAN node 421, 422 sends the requested transport related information to the first RAN node 410.

[0173] The second RAN node 421 , 422 may send the requested transport related information by any one of the following:

[0174] • sending the transport related information with a certain aggregation level requested by the first RAN node;

[0175] • sending a specific transport related information requested by the first RAN node;

[0176] • sending a specific transport related information with a certain granularity requested by the first RAN node.

[0177] Action 730

[0178] The second RAN node 421 , 422 receives updated values of transport resources from the first RAN node 410 or a third transport network node 420.

[0179] According to some embodiments herein, before sending the requested transport related information, the second RAN node 421 , 422 may perform the following actions. Action 701

[0180] The second RAN node 421 , 422 may receive one or more messages from the first RAN node 410, the one or more messages may comprise requests for reporting one or more of the following information: a) capability of reporting transport related information; b) capability of reporting a specific transport related information; c) capability of reporting a specific transport related information with a certain granularity; d) capability of reporting certain aggregation level for the transport related information; e) indications of one or more transport related information that the second RAN node 421 , 422 can offer or report.

[0181] Action 702

[0182] The second RAN node 421 , 422 may send one or more messages to the first RAN node 410, by pre-configuring or by one or more request received from the first RAN node 410. The one or more messages may comprise one or more of the following: a) indication indicating capability of reporting transport related information; b) indication indicating its capability of reporting a specific transport related information; c) indication indicating its capability of reporting a specific transport related information with a certain granularity; d) indication indicating its capability of reporting the transport related information with certain aggregation level; e) indications of one or more transport related information it can offer or report.

[0183] A method performed by a third transport network node 430 in a wireless communication network 400 for handling transport resources will be described with reference to Figure 8. The second RAN node 421, 422 is served by a first RAN node 410. The method comprises the following actions which may be performed in any suitable order and some actions may be optional.

[0184] Action 810

[0185] The third transport network node 430 may receive a message from the first RAN node 410. The message comprises a request or indication for requesting or indicating whether updating transport resources is needed for one or more second RAN nodes 421, 422.

[0186] According to some embodiments herein, the third transport network node 430 may determine whether updating transport resources is needed for the one or more second RAN nodes 421, 422, then the method may further comprises the following actions.

[0187] Action 811

[0188] The third transport network node 430 may receive transport related information from the first RAN node 410. The transport related information comprises a set of transport network metrics related to transport resource utilization, reported by the one or more second RAN nodes 421 , 422.

[0189] Action 812

[0190] The third transport network node 430 determines whether updating transport resources is needed for the one or more second RAN nodes 421 , 422 based on the reported transport related information from the one or more second RAN nodes 421 , 422 and provisioned capacity

[0191] Action 820

[0192] The third transport network node 430 takes actions to update transport resources for the one or more second RAN nodes 421 , 422 based on the message.

[0193] The third transport network node 430 may take one or more of the following actions to update transport network resources for the one or more second RAN nodes:

[0194] • determining updated values of transport resources for the one or more second RAN nodes 421 , 422;

[0195] • setting transport network related configuration parameters for the one or more second RAN nodes 421 , 422;

[0196] • allocating a maximum amount of bandwidth to traffic mapped to a certain Class of Service, or to certain group of Class of Services;

[0197] • increasing or reducing the bandwidth allocated to a certain transport path between two or more second RAN nodes 421, 422;

[0198] • selecting a certain path to carry user plane data;

[0199] • temporarily enabling or disabling the use of certain transport user plane path;

[0200] • changing the priority of the user plane carried between two or more second RAN nodes 421, 422.

[0201] Action 830 The third transport network node 430 sends updated values of the transport resources to the first RAN node 410 or to the respective one or more second RAN nodes 421 , 422.

[0202] According to embodiments herein, the first RAN node 410 may be an RAN-Cll or a gNB-Cll, or a node between an RAN-CU / gNB-CU, and one or more RAN-DUs served by the RAN-Cll. The second RAN node 421 , 422 may be an RAN-Dll served by the RAN- Cll or gNB-Dll, and the third transport network node 430 may be any one of a Transport Controller, a Transport Planning System, a Transport Software Defined Network Controller (T-SDNc), a Transport Service Orchestrator, or any other Transport Traffic Engineering Tool.

[0203] Figure 9 shows a possible cloud implementation according to embodiments herein. The solutions in E-UTRAN or NG-RAN will typically be in the Radio Control Function (RCF) in an eNB, gNB or ng-eNB which may be implemented in the centralized environment, i.e. the cloud. So the new functions or features RTA / RTE for handling transport resources may be implemented in RCF, and the RTA may be implemented in one or more distributed Radio Node (RNs). The physical location of RCF may be close to the RN or in a data center or in another hardware entity somewhere in-between.

[0204] To perform the methods in the first Ran nodes 410, the first RAN node 410 comprises modules as shown in Figure 10. The first RAN node 410 comprises a receiving module 1010, a transmitting module 1020, a determining module 1030, a processing module 1040, a memory 1050 etc.

[0205] The first RAN node 410 is configured to perform any one of the Actions 601-660 described above.

[0206] The first RAN node 410 is configured to, by means of e.g. the transmitting module 1020 being configured to, send a request to one or more second RAN nodes 421 , 422 for requesting transport related information from the one or more second RAN nodes 421 , 422, wherein the transport related information comprises a set of transport network metrics related to their transport resource utilization (TRU).

[0207] The first RAN node 410 is further configured to, by means of e.g. the transmitting module 1020 being configured to, send a request to a third transport network node (430) for requesting transport related information from the third transport network node (430), wherein the transport related information comprises a set of transport network metrics related to transport resource capacity (TRC).

[0208] The first RAN node 410 is further configured to, by means of e.g. the determining module 1030 or processing module 1040 being configured to, determining or obtaining indication whether the TRU of the one or more second RAN nodes 421, 422 and / or the TRC provisioned by the third transport network node 430 need to be adjusted based on the reported TRU and provisioned TRC.

[0209] To perform the methods in the second Ran nodes 421 , 422, the second RAN node 421 , 422 comprises modules as shown in Figure 11. The second RAN node 421 , 422 comprises a receiving module 1110, a transmitting module 1120, a determining module 1130, a processing module 1140, a memory 1150 etc.

[0210] The second RAN node 421 , 422 is configured to perform any one of the Actions 701-730 described above.

[0211] The second RAN node 421 , 422 is configured to, by means of e.g. the receiving module 1110 being configured to, receive a request from the first RAN node 410 to report transport related information, wherein the transport related information comprises a set of transport network metrics related to transport resource utilization.

[0212] The second RAN node 421 , 422 is further configured to, by means of e.g. the transmitting module 1120 being configured to, send the requested transport related information to the first RAN node (410).

[0213] The second RAN node 421 , 422 is further configured to, by means of e.g. the receiving module 1110 being configured to, receives updated values of transport resources from the first RAN node 410 or a third transport network node 430.

[0214] To perform the methods in the third transport network node 430, the third transport network node 430 comprises modules as shown in Figure 12. The third transport network node 430 comprises a receiving module 1210, a transmitting module 1220, a determining module 1230, a processing module 1240, a memory 1250 etc.

[0215] The third transport network node 430 is configured to perform any one of the Actions 810-830 described above.

[0216] The third transport network node 430 is configured to, by means of e.g. the receiving module 1110 being configured to, receive a message from a first RAN node 410, wherein the message comprises a request or indication for requesting or indicating whether updating transport resources is needed for one or more second RAN nodes 421, 422.

[0217] The third transport network node 430 is further configured to, by means of e.g. the a processing module 1240 being configured to, take actions to update transport resources for the one or more second RAN nodes 421 , 422 based on the message.

[0218] The third transport network node 430 is further configured to, by means of e.g. transmitting module 1220 being configured to, send updated values of the transport resources to the first RAN node 410 or to the respective one or more second RAN nodes 421 , 422.

[0219] The methods according to embodiments herein may be implemented through one or more processors, such as the processor 1060 / 1160 / 1260 in the first / second / third network nodes 410 / 421 ,422 / 430 together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of computer readable medium or a data carrier 1080 / 1180 / 1280 carrying computer program code 1070 / 1170 / 1270, as shown in Figures 10 / 11 / 12, for performing the embodiments herein when being loaded into the first / second / third network nodes 410 / 421, 422 / 430. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server or a cloud and downloaded to the first / second / third network nodes 410 / 421 , 422 / 430.

[0220] To summarize, new functions or features of RTA and RTE are implemented in a multiplicity of network nodes to handle transport resources.

[0221] The RTA function in a network node, e.g. the second RAN node RAN DU 421, RAN DU 422, monitors transport resource usages, e.g. TNL QoS, TNL available transport capacity etc., and reports related metrics, e.g. TNL parameters and / or TNL performances to the RTA / RTE function hosted in an RAN CU, e.g. the first RAN node 410.

[0222] The RTA / RTE function in the first RAN node 410 collects from the third transport network node 430, e.g. T-SDNc, the provisioned / offered capacity relevant to the links between the first and second RAN nodes and compares the offered capacity and available capacity reported by the RTA function in the respective second RAN nodes, i.e. RAN DU 421, RAN DU 422. Based on the received information concerning the TNL resource usage, the RTA / RTE function in the first RAN node 410 determines or obtains an indication from the third transport network node 430 or another network node or entity or function within or outside the first RAN node 410, that new or updated TNL resources are needed. That is whether the transport resource utilization of the one or more second RAN nodes 421 , 422 and / or the transport resource capacity provisioned by the third transport network node 430 need to be adjusted is determined based on the reported transport resource utilization and provisioned transport resource capacity.

[0223] The RTA / RTE function in the first RAN node 410 requests the new or updated TNL resources to the third transport network node 430, e.g. T-SDNc.

[0224] The third transport network node 430 determines new or updated transport resources, e.g. TNL Offered Capacity or other TNL related configuration parameter(s), for the one or more second RAN nodes, e.g. RAN DU 421 , 422.

[0225] The new or updated transport resources are sent to the one or more second RAN nodes, e.g. RAN DU 421 , 422.

[0226] In this way, dynamic remapping of the RAN network slices over the Transport network slices is realized by setting the new or updated TNL Offered Capacity or other TNL related configuration parameter(s) for one or more RAN DUs. The setting can be performed indirectly, i.e. , the third transport network node 430 T-SDNc may send the new mapping, i.e. the new or updated TNL Offered Capacity or other TNL related configuration parameter(s), to the first RAN node RAN CU 410, which in turns sends the new mapping to one or more second RAN nodes, e.g. RAN DU 421 , 422, or directly, i.e., the third transport network node 430 may send the new mapping directly to one or more second RAN nodes, e.g. RAN DU 421, 422.

[0227] Embodiments herein provide some advantages for examples:

[0228] • Close-loop transport resource optimization with feedback from transport network metrics.

[0229] • Better transport resource optimization, adaptive allocation of transport network slices.

[0230] • Total cost of ownership (TCO) improvement by better use of bandwidth and transport network.

[0231] • Improved performance of the e2e 5G or 6G services with guaranteed QoS.

[0232] • Leverages on existing 3GPP protocol stack, self-confined and RAN transparent in transport nodes. • Smooth integration of radio and transport interaction, supporting different functional splits.

[0233] The word "comprise" or “comprising”, when used herein, shall be interpreted as non- limiting, i.e. meaning "consist at least of".

[0234] The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the invention, which is defined by the appended claims.

Claims

Claims1 . A method performed by a first radio access network, RAN, node (410) in a wireless communication network (400) for handling transport resources for one or more second RAN nodes (421 , 422) served by the first RAN node (410), the method comprising: sending (610) a request to one or more second RAN nodes (421 , 422) for requesting transport related information from the one or more second RAN nodes (421 , 422), wherein the transport related information comprises a set of transport network metrics related to their transport resource utilization, TRU; sending (620) a request to a third transport network node (430) for requesting transport related information from the third transport network node (430), wherein the transport related information comprises a set of transport network metrics related to transport resource capacity, TRC; determining or obtaining indication (630) whether the TRU of the one or more second RAN nodes (421 , 422) and / or the TRC provisioned by the third transport network node (430) need to be adjusted based on the reported TRU and provisioned TRC.

2. The method according to claims 1 , wherein the transport related information comprises one or more or any combination of the following: a) Downlink, DL, and / or uplink, UL, transport network layer, TNL, Offered Capacity at different granularities; b) DL and / or UL TNL Available Capacity at different granularities; c) DL and / or UL TNL Available Bandwidth at different granularities; d) Latency at different granularities; e) Round trip time at different granularities; f) Packet error rate in downlink and / or uplink and at different granularities; g) Packet drop rate or packet loss in downlink and / or uplink at different granularities; h) Queuing delay in downlink and / or uplink at different granularities; i) Quality of Service (QoS) related information at different granularities.

3. The method according to any one of claims 1- 2, wherein the first RAN node determines whether the TRC and / or TRU needs to be adjusted by comparing reported TRU and provisioned TRC.

4. The method according to any one of claims 1- 3, further comprising sending (640) a message to the third transport network node (430) for adjusting TRU for the one or more second RAN nodes (421, 422) and / or TRC provisioned by the third transport network node (430).

5. The method according to claim 4, wherein the message for adjusting TRU and / or TRC comprises one or more of the following: a) a request to increase TRC pertaining to the first RAN node and the one or more second RAN nodes; b) a request to reallocate transport network resources pertaining to a certain second RAN node to another second RAN node; c) a request to reallocate transport network resources pertaining to a certain second RAN node to another specific second RAN node; d) an indication that TRC pertaining to a certain second RAN node is not sufficient; e) an indication that TRC pertaining to a certain second RAN node is sufficient; f) an indication that a certain difference between transport network resources pertaining to a certain second RAN node is too low, either in absolute values or in percentage.

6. The method according to claim 4, wherein the message for adjusting TRU and / or TRC comprises one or more of the following: g) an indication that DL and / or UL TNL Offered Capacity pertaining to a certain second RAN node is not sufficient; h) an indication that DL and / or UL TNL Available Capacity pertaining to a certain second RAN node is low, or too low, or lower than a threshold; i) an indication that DL and / or UL TNL Offered Capacity pertaining to a certain second RAN node is sufficient; j) an indication that DL and / or UL TNL Available Capacity pertaining to a certain second RAN node is high, or higher than a threshold; k) an indication that DL and / or UL TNL Available Capacity pertaining to a certain second RAN node is critical.

7. The method according to any one of claims 1-6, further comprising sending (601) one or more messages to the one or more second RAN nodes (421 , 422) to request one or more of the following information: a) capability of reporting transport related information; b) capability of reporting a specific transport related information; c) capability of reporting a specific transport related information with a certain granularity; d) capability of reporting certain aggregation level for the transport related information; e) one or more transport related information that the second RAN node can offer or report.

8. The method according to claim 7, further comprising receiving (602) one or messages from the one or more second RAN nodes, wherein the one or more messages comprises one or more indications indicating the requested information.

9. The method according to any one of claims 1-8, wherein the request sent to one or more second RAN nodes to report transport related information further comprises one or more of the following: a) request to provide a certain aggregation level for the transport related information; b) request to provide a specific transport related information; c) request to provide a specific transport related information with a certain granularity.

10. The method according to any one of claims 1-9, wherein a granularity of the transport related information requested or reported is any one or a combination of the following: a) per network node, b) per Class of Service, c) per group of Class of Services, d) per cell, e) per network slice, f) per type of spectrum, g) per Radio Access Technology,h) per reference signal beam; i) per QoS flow per user equipment (UE); j) per UE; k) per General Packet Radio Service Tunneling Protocol in User Plane (GTP- U) path.

11. The method according to any one of claims 1-10, further comprising: receiving (650) updated values of transport resources from the third transport network node (430); and sending (660) the updated values of transport resources to the one or more second RAN nodes (421 , 422).

12. The method according to any one of claims 1-11, wherein values of the set of transport network metrics are reported as any one or a combination of the following: a) maximum / minimum / average values of a transport network metric; b) distribution values of a transport network metric; c) an offset value compared to a reference or threshold value for a transport network metric; d) a percentage of the values collected for a transport network metric during a time period which are fulfilled a certain criterion; e) a percentage of users for which the values collected for a transport network metric during a time period are fulfilled a certain criterion.

13. The method according to any one of claims 1-12, further comprises sending (631) the transport related information as received from the one or more second RAN nodes or in an aggregated format to the third transport network node.

14. A method performed by a second radio access network, RAN, node (421 , 422) for handling transport resources in a wireless communication network (400), wherein the second RAN node (421 , 422) is served by a first RAN node (410), the method comprising: receiving (710) a request from the first RAN node (410) to report transport related information, wherein the transport related information comprises a set of transport network metrics related to transport resource utilization; sending (720) the requested transport related information to the first RAN node (410);receiving (730) updated values of transport resources from the first RAN node (410) or a third transport network node (430).

15. The method according to claim 14, further comprising: receiving (701) one or more messages from the first RAN node (410), wherein the one or more messages comprise requests for reporting one or more of the following information: i. capability of reporting transport related information; ii. capability of reporting a specific transport related information; iii. capability of reporting a specific transport related information with a certain granularity; iv. capability of reporting certain aggregation level for the transport related information; v. indications of one or more transport related information that the second RAN node (421 , 422) can offer or report.

16. The method according to claims 14 or 15, further comprising: sending (702) one or more messages to the first RAN node before sending the requested transport related information, wherein the one or more messages comprises one or more of the following: a) indication indicating capability of reporting transport related information; b) indication indicating its capability of reporting a specific transport related information; c) indication indicating its capability of reporting a specific transport related information with a certain granularity; d) indication indicating its capability of reporting the transport related information with certain aggregation level; e) indications of one or more transport related information it can offer or report.

17. The method according to any one of the claims 14-16, wherein sending (720) the requested transport related information comprises one or more of the following: a) sending the transport related information with a certain aggregation level requested by the first RAN node;b) sending a specific transport related information requested by the first RAN node; c) sending a specific transport related information with a certain granularity requested by the first RAN node.

18. A method performed by a third transport network node (430) for handling transport resources in a wireless communication network (400), the method comprising: receiving (810) a message from a first radio access network, RAN, node (410), wherein the message comprises a request or indication for requesting or indicating whether updating transport resources is needed for one or more second RAN nodes (421 , 422); taking actions (820) to update transport resources for the one or more second RAN nodes (421, 422) based on the message; sending (830) updated values of the transport resources to the first RAN node (410) or to the respective one or more second RAN nodes (421 , 422).

19. The method according to claim 17, wherein taking actions (820) to update transport network resources for the one or more second RAN nodes (421 , 422) comprises any one or more of the following: a) determining updated values of transport resources for the one or more second RAN nodes (421, 422); b) setting transport network related configuration parameters for the one or more second RAN nodes (421 , 422); c) allocating a maximum amount of bandwidth to traffic mapped to a certain Class of Service, or to certain group of Class of Services; d) increasing or reducing the bandwidth allocated to a certain transport path between two or more second RAN nodes; e) selecting a certain path to carry user plane data; f) temporarily enabling or disabling the use of certain transport user plane path; g) changing the priority of the user plane carried between two or more second RAN nodes (421, 422).

20. The method according to any one of claims 17-19, further comprising:receiving (840) transport related information from the first RAN node (410), wherein the transport related information comprises a set of transport network metrics related to transport resource utilization, reported by the one or more second RAN nodes (421, 422); determining (850) whether updating transport resources is needed for the one or more second RAN nodes (421 , 422) based on the reported transport related information from the one or more second RAN nodes (421, 422) and provisioned capacity.

21. The method according to any one of claims 1-19, wherein the first RAN node (410) is a Radio Access Network Central Unit, RAN-CU or a gNB-CU, the second RAN node (421, 422) is a Radio Access Network Distributed Unit, RAN-DU, served by the RAN- CU or a gNB-DU, and the third transport network node (430) is any one of a Transport Controller, a Transport Planning System, a Transport Software Defined Network Controller, T-SDNc, a Transport Service Orchestrator, or any other Transport Traffic Engineering Tool.

22. The method according to any one of claims 1-19, wherein the first RAN node (410) is a node between a Radio Access Network Central Unit, RAN-CU or a gNB-CU, and one or more Radio Access Network Distributed Units, RAN-DU, served by the RAN- CU, the second RAN node (421 ,422) is a RAN-DU or gNB-DU served by the RAN-CU or gNB-CU, and the third transport network node (430) is any one of a Transport Controller, a Transport Planning System, a Transport Software Defined Network Controller, T-SDNc, a Transport Service Orchestrator, or any other Transport Traffic Engineering Tool .

23. A first RAN node (410) for handling transport resources in a wireless communication network (400), wherein the first RAN node (410) is configured to perform the method according to any one of claims 1-13.

24. The first RAN node (410) according to claim 22 is implemented in a Radio Access Network Central Unit, RAN-CU, or is implemented as a transport network node between a Radio Access Network Central Unit, RAN-CU or a gNB-CU, and one or more Radio Access Network Distributed Units, RAN-DU or a gNB-DU, served by the RAN-CU.

25. A second RAN node (421 , 422) for handling transport resources in a wireless communication network (400), wherein the second RAN node (421 , 422) is configured to perform the method according to any one of claims 14-17.

26. The second RAN node (421 , 422) according to claim 25, is a RAN-Dll served by a RAN-CU.

27. A third transport node (430) for handling transport resources in a wireless communication network (400), wherein the third transport node (430) is configured to perform the method according to any one of claims 18-20.

28. The third transport node (430) according to claim 27 is any one of a Transport Controller, a Transport Planning System, a Transport Software Defined Network Controller, T-SDNc, a Transport Service Orchestrator, or any other Transport Traffic Engineering Tool.

Images