WO2024175192A1

WO2024175192A1 - Radio unit, baseband processing unit and methods in a wireless communications network

Info

Publication number: WO2024175192A1
Application number: PCT/EP2023/054428
Authority: WO
Inventors: Stefan TJÄRNLUND; Xiaoyu WEI; Fredrik SÖDERBERG
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-02-22
Filing date: 2023-02-22
Publication date: 2024-08-29
Anticipated expiration: 2025-08-22

Abstract

A method performed by a Radio Unit, RU, for handling dynamic resources allocation in a wireless communications network is provided. The RU is associated to one or more Baseband Processing Units, BPU. Each BPU comprises one or more Baseband, BB,applications for which the resources is to be allocated. The RU receives (401) respective resource requests from the one or more BPUs. The resources are requested for a future Resource Interval, RI. The RU dynamically allocates (402), based on the respective request, resources to the one or more BB applications comprised in the respective one or more BPUs, for the future RI. The RU sends (403) a resource grant message to the one or more BPUs. The message indicates the allocated resources.

Description

RADIO UNIT, BASEBAND PROCESSING UNIT AND METHODS IN A WIRELESS

COMMUNICATIONS NETWORK

TECHNICAL FIELD

Embodiments herein relate to a radio unit and a baseband processing unit and methods therein. In some aspects, they relate to handling resource allocation in a wireless communications network.

BACKGROUND

In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or User Equipments (UE), communicate via a Wide Area Network or a Local Area Network such as a Wi-Fi network or a cellular network comprising a Radio Access Network (RAN) part and a Core Network (CN) part. 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, eNodeB (eNB), or gNB as denoted in Fifth Generation (5G) telecommunications. 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 device within range of the radio network node.

3GPP is the standardization body for specifying the standards for a cellular system evolution, e.g., including 3G, 4G, 5G and future evolutions. Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network, have been completed within the 3rd Generation Partnership Project (3GPP). As a continued network evolution, new releases of 3GPP specify a 5G network also referred to as 5G New Radio (NR).

Multi-antenna techniques may significantly increase the data rates and reliability of a wireless communication system. The performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. Such systems and/or related techniques are commonly referred to as MIMO.

In addition to faster peak Internet connection speeds, 5G planning aims at higher capacity than current 4G, allowing higher number of mobile broadband users per area unit, and allowing consumption of higher or unlimited data quantities in gigabyte per month and user. This would make it feasible for a large portion of the population to stream high-definition media many hours per day with their mobile devices, when out of reach of Wi-Fi hotspots. 5G research and development also aims at improved support of machine to machine communication, also known as the Internet of things, aiming at lower cost, lower battery consumption and lower latency than 4G equipment.

Multi-Operator Radio Access Network (MORAN) is a network sharing standard, where the RAN is shared, while the core network is proprietary to each network provider, and where a dedicated radio frequency is used by each operator/network provider. In this approach, the sharing operators/network providers may independently control the cell level, e.g., each operator may decide his own optimization parameters, traffic configurations, transmission power, etc., to control the cell capacity and interference. There are different types and amount of RAN infrastructures that may be shared, along with different deployment scenarios.

With the lower layer functional split concept being introduced in 5G NR, a Baseband Processing Unit (BPU) is disaggregated from a Radio Unit (RU) by breaking off functions between them with interoperable hardware and software components. Then in a MORAN scenario where multiple operators/network providers are to share an RU, they share both the hardware (HW) and software (SW) in RU, while they are also interoperable with their respective BPU.

In addition to a typical multi-operator sharing scenario, there are also other deployment scenarios that would require an RU to be shared by multiple BPUs. In such a deployment, multiple RU SW instances are created on the shared RU and are providing services to their respective BPU applications that are possibly running in multiple different BPUs.

SUMMARY As part of developing embodiments herein a problem was identified by the inventor and will first be discussed.

With network sharing scenarios, such as described above, follows the need for dimensioning of HW resources on the RU. Different possibilities exists for achieving this, all of which have its own problems and drawbacks.

One possibility is to over-dimension the HW resources on the Rll to support maximum traffic load on all BB applications on the BPUs. This way a no resource negotiation is needed. A problem and/or drawback is the manufacturing cost of the Rll to include all HW needed to support this strategy.

Another possibility is static resource negotiation at cell/sector carrier setup. The Rll resources are statically allocated to the BB applications on the BPUs based on configuration parameters. The problem and/or drawback with this approach is that the resource distribution needs to assume high load scenarios in all cell/sector carrier when doing the allocation of RU resources towards BB applications on the BPUs. This will normally result in a lower RU resource allocation, and hence reduced support for peak load, for a BB application on the BPU.

An object of embodiments herein is to improve the performance of the wireless communications network by providing a more efficient resource handling for shared radio network.

According to an aspect of embodiments herein, the object is achieved by a method performed by a Radio Unit, RU, for handling dynamic resources allocation in a wireless communications network. The RU is associated to one or more Baseband Processing Units, BPU. Each BPU comprises one or more Baseband, BB, applications for which the resources are to be allocated.

The RU receives respective resource requests from the one or more BPUs. The resources are requested for a future Resource Interval, Rl.

The RU dynamically allocates, based on the respective requests, resources to the one or more BB applications comprised in the respective one or more BPUs, for the future Rl.

The RU sends a resource grant message to the one or more BPUs. The message indicates the allocated resources. According to another aspect of embodiments herein, the object is achieved by a method performed by a Baseband Processing Unit, BPU, for assisting a Radio Unit, RU, in dynamically allocating resources in a wireless communications network. The BPU comprises one or more Baseband, BB, applications for which the resources are to be allocated. The BPU is associated with the RU 115.

The BPU measures a current data traffic load for the respective one or more BB applications.

The BPU predicts resources to be used by the respective one or more BB applications in a future Resource Interval, Rl.

The BPU sends a resource request to the RU 115 based on the predicted resources. The resources are requested for the future Rl.

The BPU receives a resource grant message from the RU. The message indicates resources allocated to the one or more BB applications.

According to another aspect of embodiments herein, the object is achieved by a Radio Unit, RU, configured to handle dynamic resources allocation in a wireless communications network. The RU is adapted to be associated to one or more Baseband Processing Units, BPU. Each BPU 110, 111 is adapted to comprise one or more Baseband, BB, applications for which the resources are to be allocated. The RU is further configured to:

- Receive respective resource requests from the one or more BPUs, wherein the resources are adapted to be requested for a future Resource Interval, Rl,

- dynamically allocate, based on the respective request, resources to the one or more BB applications adapted to be comprised in the respective one or more BPUs, for the future Rl, and send a resource grant message to the one or more BPUs, which message is adapted to indicate the allocated resources.

According to another aspect of embodiments herein, the object is achieved by a Baseband Processing Unit, BPU, configured to assist a Radio Unit, RU, to dynamically allocate resources in a wireless communications network. The BPU is adapted to comprise one or more Baseband, BB, applications for which the resources are adapted to be allocated. The BPU is adapted to be associated to the RU. The BPU is further configured to:

- Measure a current data traffic load for the respective BB applications, - predict resources to be used by the respective one or more BB applications in a future Resource Interval, Rl,

- send a resource request to the Rll based on the predicted resources, wherein the resources are adapted to be requested for the future Rl, and

- receive a resource grant message from the Rll, which message is adapted to indicate resources allocated to the one or more BB applications.

In this way, a more efficient resource allocation is achieved. This since when the Rll receives the respective resource requests, resources may be allocated to the one or more BB applications for the future Rl based on the predicted resource needs indicated in the respective resource requests. Embodiments herein e.g., brings the advantages of achieving an efficient resource allocation by, based on a predicted resource need for a future Rl, allocating resources to the one or more BB applications for the future Rl. Thus, the Rll may dynamically allocate resources based on the current varying need of the one or more BB applications, which results in an improved performance of the wireless communications network and an improved resource utilization by a more efficient and flexible resource allocation.

BRIEF DESCRIPTION OF THE DRAWINGS

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

Figure 1 is a schematic block diagram illustrating examples of embodiments herein.

Figure 2 is a schematic block diagram illustrating examples of embodiments herein.

Figure 3 is a schematic block diagram illustrating embodiments of a wireless communications network.

Figure 4 is a flowchart depicting embodiments of a method in a radio unit.

Figure 5 is a flowchart depicting embodiments of a method in a baseband processing unit.

Figure 6 is a schematic diagram illustrating examples of embodiments herein.

Figure 7 is a schematic block diagram illustrating examples of embodiments herein.

Figure 8 is a schematic block diagram illustrating examples of embodiments herein.

Figure 9 is a schematic block diagram illustrating examples of embodiments herein.

Figure 10 is a schematic flowchart illustrating examples of embodiments herein. Figure 11 is a schematic flowchart illustrating examples of embodiments herein.

Figure 12 is a schematic flowchart illustrating examples of embodiments herein.

Figure 13 is a schematic block diagram illustrating examples of embodiments herein.

Figure 14 is a schematic block diagram illustrating embodiments of a radio unit.

Figure 15 is a schematic block diagram illustrating embodiments of a baseband processing unit.

Figure 16 schematically illustrates a telecommunication network connected via an intermediate network to a host computer.

Figure 17 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection,

Figures 8-21 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station, and a user equipment.

DETAILED DESCRIPTION

Embodiments herein relate to a wireless communications network and the allocation of resources to one or more BB applications comprised, or implemented, in one or more BPUs in a wireless communications network.

As mentioned above, an object of embodiments herein is to improve the performance of the wireless communications network by providing a more efficient resource handling for shared radio networks.

This may e.g., be achieved by introducing a dynamic resource negotiation between BPll(s) and a Rll in the case of sharing the Rll among multiple BB applications on the BPll(s). A BPU may have one or multiple BB applications executing there.

MORAN is a network sharing standard, where the RAN is shared, while the core network is proprietary to each network provider, and where a dedicated radio frequency is used by each operator/network provider. In this approach, the sharing operators/network providers may independently control the cell level, e.g., each operator may decide his own optimization parameters, traffic configurations, transmission power, etc., to control the cell capacity and interference. There are different types and amount of RAN infrastructures that may be shared, along with different deployment scenarios. One of the major variations is multiple-baseband MORAN, as shown in Figure 1 , where a separate BPU is used by each operator/network provider, but the Rll is shared.

With the lower layer functional split concept being introduced in 5G NR, BPU is disaggregated from RU by breaking off functions between them with interoperable hardware and software components. Then in a MORAN scenario where multiple operators/network providers are to share an RU, they share both the HW and software SW in RU, while they are also interoperable with their respective BPU.

In addition to a typical multi-operator sharing scenario, there are also other deployment scenarios that would require an RU to be shared by multiple BPUs, as shown in Figure 2. In such a deployment, multiple RU SW instances are created on the shared RU and are providing services to their respective BPU applications that are possibly running in multiple different BPUs. The typical BPU application configurations that could drive the increased RU SW instances to share one RU and therefore the RU’s HW computational resources, may include: operator, BPU type, e.g., DU and vDU; RAT type, e.g., LTE and NR, frame structure type, e.g., FDD and TDD, TDD pattern, numerology, e.g., 15kHz/30kHz/120kHz subcarrier spacing.

Figure 3 is a schematic overview depicting a wireless communications network 100 wherein embodiments herein may be implemented. The wireless communications network 100 comprises one or more RANs and one or more CNs. The wireless communications network 100 may use a number of different technologies, such as Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, 5G, New Radio (NR), 6G, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations. Embodiments herein relate to recent technology trends that are of particular interest in a 5G context, however, embodiments are also applicable in further development of the existing wireless communication systems such as e.g. WCDMA and LTE.

A number of RAN nodes operate in the communications network 100 such as e.g., the RU 115. The RU 115 provides radio coverage in a number of cells which may also be referred to as a beam or a beam group of beams, such as a cell 11 and a cell 12.

The RU 115 may be any of an NG-RAN node, a transmission and reception point e.g. a base station, a radio access network node such as a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), a gNB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of communicating with a UE, such as e.g., a UE 121 , within the service area served by the Rll 115 depending e.g. on the radio access technology and terminology used. The Rll 115 may be referred to as a serving RAN node and communicates with UEs such as the UE 121, with Downlink (DL) transmissions to the UE121 , and in Uplink (UL) transmissions from the UE 121.

A number of network nodes, such as e.g., the one or more BPUs 110, 111, operate in the wireless communications network 100. The one or more BPUs 110, 111 are associated to the RU 115. The one or more BPUs 110, 111 respectively comprises, or implements, one or more BB applications 110a-b, 111a-b (not shown). The one or more BPUs 110, 111 may belong to different operators, e.g., in a MORAN scenario. Alternatively, or additionally, the one or more BPUs 110, 111 be Open RAN (O-RAN) nodes, operating in an O-RAN configuration.

A number of UEs, such as e.g., the UE 121 , operate in the wireless communication network 100. The UE 121 may also be referred to as an loT device, a mobile station, a non-access point (non-AP), a STA, and/or a wireless terminal. It should be understood by the skilled in the art that “UE” is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, a radio device in a vehicle, or node e.g., smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station communicating within a cell.

Methods herein may be performed by the RU 115 and the BPU 110. As an alternative, a Distributed Node (DN) and functionality, e.g. comprised in the cloud 150 as shown in Figure 1, may be used for performing or partly performing the methods herein.

According to examples of embodiments herein, a method and a RU 115 for allocating resources is provided. Further, a method and BPU 110 for assisting the RU 110 allocating resources is provided. The methods, RU 115 and BPU 110 may e.g., overcome the above mentioned problem to fully use of the available HW compute resources on the RU 115 in the case when being shared among multiple BPUs 110 by introducing a dynamic resource negotiation procedure between BB applications on the BPUs 110 and the shared RU 115.

By dynamically allocating the HW compute resources to fit the actual traffic need, better HW utilization may be achieved and thereby better peak capacity can be maintained for cases with unbalanced traffic on the BPUs 110.

The BPU 110, or the BB applications on the BPUs 110 and the RU 115, or application running on the RU 115, are negotiating for how much RU resources a BB application is allowed to use. The resources, such as e.g., radio resources, are granted for a limited time, such interval is referred to as a Resource Interval (Rl) or Radio Rl (RRI), and new negotiations may be needed for each such Rl or RRI.

In cases of unbalanced traffic between the BB applications, which may be very common in network deployment, a majority of the resources on the RU 115 may be granted to the BB applications with high traffic demand. Only a minimum set of HW resource may be allocated to the BPUs with no or little traffic. This result is better capacity support for BPUs compared to a pure static split of HW resources on the RU 115.

A number of embodiments will now be described, some of which may be seen as alternatives, while some may be used in combination.

The embodiments of a method will be generally described in view of the RU 115 together with Figure 4 and in view of the BPU 110 together with Figure 5. This will be followed by a more detailed description.

A method according to embodiments herein will now be described from the view of the RU 115, together with Figure 4. Figure 4 depicts example embodiments of a method performed by the RU 115 for handling dynamic resources allocation in the wireless communications network 100. The RU 115 is associated to one or more BPUs 110, 111. Each BPU 110, 111 comprises one or more BB applications 110a-b, 111a-b for which the resources are to be allocated. The RU 115 may also be referred to as a Remote Unit, Radio Processing Unit or Remote processing Unit. The one or more BPUs 110, 111 may share the resources of the RU 115. The one or more BPUs 110, 111 may belong to different operators, e.g., in a MORAN scenario. Alternatively, or additionally, the one or more BPUs 110, 111 be O-RAN nodes, operating in an O-RAN configuration.

The method comprises the following actions, which actions may be taken in any suitable order. Actions that are optional are presented in dashed boxes in Figure 4.

Action 401

To efficiently allocate resources to the one or more BB applications 110a-b, 111a-b in the one or more BPUs 110, 111, it may be beneficial for the RU 115 to be aware of the resources the one or more BPUs 110, 111 needs.

Therefore, the RU 115 receives respective resource requests from the one or more BPUs 110, 111. The resources are requested for a future Rl . The RU 115 may receive one respective resource request from each of the one or more BPUs 110, 111. In such an example, a respective resource request may comprise one or more predicted resources indications. Each of the one or more predicted resources indication may be associated to a respective BB application 110a-b, 111a-b comprised in the BPU 110, 111 sending the resource request. The one or more predicted resource indications may indicate the resources predicted to be needed by the associated BB application 110a-b, 111a-b in the future Rl. Alternatively, the RU 115 may receive one resource request from each BB application 110a-b, 111a-b comprised in the one or more BPUs 110, 111. In other words, the RU 115 may receive one or more resource request from each of the one or more BPUs 110, 111, where each respective resource request is associated to a respective BB application 110a-b, 111a-b.

The future Rl may be immediately subsequent to a current Rl. This may mean that the future Rl is the next Rl following the current Rl. In other words, a resource request received during a current Rl may indicate resources requested for the Rl directly following the current Rl.

An Rl may be defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1. The length of the radio frame may be measured in a time unit, from which follows that an Rl may also be measured in a time unit. Thus, an Rl may be defined as the length, or size, of a radio frame measured in a time unit multiplied with a parameter such as K, where K is defined as mentioned above. In some examples, the Rl may also be referred to as a Radio Rl (RRI). Rl and RRI may be used interchangeably during the following of this disclosure.

In some embodiments, the requested resources are radio resources. The requested resources, e.g., radio resources, may comprise any one or more out of:

Physical Resource Blocks (PRB), e.g., a number of PRBs, radio layers, e.g., number MIMO layers

- MIMO type, e.g., Single User MIMO (SU-MIMO) or Multiuser MIMO (MU-MIMO), beamforming scheme, number of antenna streams to be used for a transmission, e.g., a maximum and/or minimum number of antenna streams, number of transmissions per slot, transmission timing within the Rl, transmission power, e.g., for DL physical channels, modulation coding scheme (MOS) to be used for a transmission, e.g., a highest and/or lowest MOS allowed, number of Demodulation Reference Signal (DM RS) symbols to be used for a transmission, e.g., maximum number of DMRS symbols, a type of receiver processing chain to be used for UL transmissions, e.g., Reciprocity Assisted Transmission (RAT) receiver or Reciprocity Assisted Interference-aware Transmission (RAIT) receiver, and a priority indicator, e.g., indicating a priority of requested resources.

The resources may be implicitly or explicitly indicated in the respective resource request. Implicitly indicated resources may e.g., be indicated by any one out of: a bitmap, or an index. The RU 115 may determine the implicitly indicated resources by mapping the index or bitmap to e.g., a table configured in the RU 115. In some examples the requested resources may be indicated by both one or more indices and one or more bitmaps.

Action 402

The RU 115 dynamically allocates, based on the respective request, resources to the one or more BB applications 110a-b, 111a-b comprised in the respective one or more BPUs 110, 111 for the future Rl. Dynamically allocating when used herein may e.g., mean that the resources are allocated for one future Rl at the time. Thus, the allocation may change for every Rl, based on the amount requested resources. This allows a flexible method for allocating resources, leading to an efficient resource allocation and improved performance in the wireless communications network 100. In some embodiments, dynamically allocating the resources comprises the RU 115 repeatedly, during each Rl, performing the steps of receiving (see Action 401), allocating (see Action 402) and sending (see Action 403). In other words, the Rll 115 may, in some embodiments, during each Rl allocate resources to the one or more BB applications 110a-b, 111a-b for a future Rl. This by e.g., during each Rl, receiving the respective resource requests, allocating the resources, and as described below in Action 403, sending a resource grant message.

In some embodiments, allocating the resources comprises the Rll 115 to determine the resources to be allocated to the respective BB applications 110a-b, 111a-b. The Rll 115 determines the resources to be allocated taking available resources in the Rll 115 into account. In other words, the resources to be allocated may be limited by the amount of available resources in the Rll 115. This may mean that the allocation of the resources is performed in order to e.g., maximize the utilization of the available resources, fulfill the need of the one or more BB applications 110a-b, 111 a-b, and/or guaranteeing a minimum set or amount of resources to the one or more BB applications 110a-b, 111 a-b. In some examples, the allocation of the resources comprises allocating based on different priorities of the one or more BB applications 110a-b, 111 a-b. alternatively, or additionally, the Rll 115 may allocate the resources based on a request for critical resources for a BB application, e.g., indicated in the resource request.

Action 403

The Rll 115 sends a resource grant message to the one or more BPUs 110, 111. The message indicates the allocated resources. As for the resource request mentioned above, the allocated resources may be implicitly or explicitly indicated to the one or more BPUs 110, 111 in the resource grant message.

A method according to embodiments herein will now be described from the view of the BPU 110, together with Figure 5. Figure 5 depicts example embodiments of a method performed by the BPU 110 for assisting the RU 115 in dynamically allocating resource in the wireless communications network 100. The BPU 110 comprises one or more BB applications 110a-b for which the resources are to be allocated. The BPU 110 is associated to the RU 115. The BPU 110 may belong to a different operator than another BPU, e.g., the BPU 111 , also associated to the RU 115, e.g., in a MORAN scenario. Alternatively, or additionally, the BPU 110 may be an O-RAN nodes, operating in an O- RAN configuration.

The method comprises the following actions, which actions may be taken in any suitable order. Actions that are optional are presented in dashed boxes in Figure 5.

Action 501

The BPU 110 measures a current data traffic load for the respective one or more BB applications 110a-b. E.g., the BPU 110 measures the current data traffic load during a current Rl. In some embodiments, the BPU 110 measures the current traffic load for the respective one or more BB applications 110a-b during each Rl.

Action 502

The BPU 110 predicts resources to be used by the respective one or more BB applications 110a-b in the future Rl. The BPU 110 may predict the resources based on the measured traffic data load. In some examples, the prediction is further based on the data traffic loads measured during one or more earlier RIs, e.g., one or more RIs other than the current Rl. In other words, the BPU 110 may predict the resources based measured data traffic load of the current Rl and, in some examples, on historical measured data traffic loads.

In some embodiments, the BPU 110 predicts, during each current Rl, the resources to be used by the respective one or more BB applications 110a-b in the future Rl. In other words, the BPU 110, during each Rl, may predict the resources to be used by the respective one or more BB applications 110a-b, in the future Rl.

As mentioned above, an Rl may be defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1. The length of the radio frame may be measured in a time unit, from which follows that an Rl may also be measured in a time unit. Thus, an Rl may be defined as the length, or size, of a radio frame measured in a time unit multiplied with a parameter such as K, where K is defined as mentioned above. In some examples, the Rl may also be referred to as a Radio Rl (RRI). Rl and RRI may be used interchangeably during the following of this disclosure. Action 503

The BPU 110 sends a resource request to the RU 115 based on the predicted resources. The resources are requested for the future Rl. The BPU 110 may, in some examples, send one resource request. In such an example, the resource request may comprise one or more predicted resources indications. Each of the one or more predicted resources indication may be associated to a respective BB application 110a-b comprised in the BPU 110. The one or more predicted resource indications may indicate the resources predicted to be needed by the associated BB application 110a-b in the future Rl. Alternatively, the BPU 110 may send one resource request from each BB application 110a-b comprised in the BPUs 110. In other words, the BPU 110 may send one or more resource requests, where each resource request is associated to a respective BB application 110a-b.

In some embodiments, the BPU 110 sends the resource request to the RU 115 during each current Rl. In other words, the BPU 110 may, during each Rl, send the resource request based on the predicted resources, where the resources are requested for the future Rl.

In some embodiments, the requested resources are radio resources.

The requested resources, e.g., radio resources, may comprise any one or more out of:

- MIMO type, e.g., Single User MIMO (SU-MIMO) or Multiuser MIMO (MU-MIMO), beamforming scheme, number of antenna streams to be used for a transmission, e.g., a maximum and/or minimum number of antenna streams, number of transmissions per slot, transmission timing within the Rl, transmission power, e.g., for DL physical channels, modulation coding scheme (MOS) to be used for a transmission, e.g., a highest and/or lowest MOS allowed, number of Demodulation Reference Signal (DMRS) symbols to be used for a transmission, e.g., maximum number of DMRS symbols, and a type of receiver processing chain to be used for UL transmissions, e.g., Reciprocity Assisted Transmission (RAT) receiver or Reciprocity Assisted Interference-aware Transmission (RAIT) receiver, and a priority indicator, e.g., indicating a priority of requested resources.

The resources may be implicitly or explicitly indicated in the respective resource request. Implicitly indicated resources may e.g., be indicated by any one out of: a bitmap, or an index. The RU 115 may determine the implicitly indicated resources by mapping the index or bitmap to e.g., a table configured in the Rll 115. In some examples the requested resources may be indicated by both one or more indices and one or more bitmaps.

Action 504

The BPU 110 receives a resource grant message from the Rll 115. The message indicates resources allocated to the one or more BB applications 110a-b. As for the resource request mentioned above, the allocated resources may be implicitly or explicitly indicated to the BPU 110 in the resource grant message.

In some embodiments, the BPU 110 receives a resource grant message during each current Rl. In other words, the BPU 110 may, during each Rl, receive a resource grant message from the RU 115, where the message indicates resources allocated to the one or more BB applications 110a-b.

Action 505

In some embodiments, the BPU 110 schedules the allocated resource to the one or more BB applications 110a-b according to the received resource grant message. Since the allocated resources have been granted for the future Rl, the BPU 110 may schedule the allocated resources for the future Rl.

In other words, each of the one or more BB applications 110a-b receives and is scheduled the resources allocated by the RU 115. This may mean that in some examples a certain BB application is scheduled with all the resources that it requested. This is since the allocation of resources may be limited by the total amount of available resources in the RU 115.

In some embodiments, the BPU 110 schedules the allocated resources to the one or more BB applications 110a-b during each current Rl. In other words, the BPU 110 may, for each Rl, schedule the allocated resources to the one or more BB applications 110a-b according to the received resource grant message. Embodiments mentioned above will now be further described and exemplified. The embodiments below are applicable to and may be combined with any suitable embodiment described above.

In a low to medium loaded cell, traffic requiring high throughput normally comes in bursts of 100-150ms. Figure 6 shows an example with a burst of 100ms.

Between bursts there may be long idle times. When connecting many cells and/or sector carriers to same RU, such as the Rll 115, those bursts will normally occur with low correlation with each other. Some cells and/or sector carriers might be in high load while others are in low load. It is an extreme case to have all cells and/or sector carriers in high load. Due to this behavior, there is an opportunity for dynamic allocation of resources, such as HW resources or radio resources, on the Rll 115:

- Cell and/or sector carrier with a high traffic load may be allocated large amounts of Rll resources

- Cell and/or sector carrier with no or low traffic load may be allocated small amount of Rll resources.

A BB application, such as one or the BB applications 110a-b, 111a-b, schedules and manages the traffic, e.g., in one or more cells and/or sector carriers. Thus, a BB application may measure and predict how much Rll resources are needed for those cells and/or sector carriers the BB application is responsible for.

To be able to dynamically allocate Rll resources to a BB application, there is a need to introduce a negotiation procedure between the BB applications on the BPU, such as the BPU 110, 111 and the RU 115.

Figure 7 shows multiple BB schedulers collaborating with a RU Resource handler, e.g., in the RU 115, over the fronthaul for RU resource negotiation. As may be seen in Figure 6, the resource handler in the shared RU 115 communicates and negotiates with the BB schedulers of all its connected BB applications in the BPUs, via the fronthaul.

The functionalities performed by the BB scheduler in BPU typically are:

- Measure ongoing traffic load

- Predict and request the needed radio resources by its connected RU SW instance

- Schedule UL/DL traffic

The functionalities performed by the RU resource handler typically are: - Collect the requested radio resources by all connected BB applications

- Allocate radio resources to each BB application based on the demand

- Notify all connected BB application the granted radio resources

Radio Resource Negotiation

A core part of the radio resource negotiation is to introduce a time interval with stable resource situation for the BPU, such as the BPU 110, 111. Such time interval is, as mentioned above, referred to as an Rl or RRI. An example of this is shown in Figure 8.

The Rl, or RRI, may be defined as Rl = K * Radio frame, the radio frame may e.g., be a 3GPP standard time frame of 10ms, in which case the Rl = K * 10ms. Normally K >=1 but if fast negotiation is needed then 0 < K < 1.

To decide the resource available for a BPU, such as the BPU 110, 111 , or BB application such as the BB application 110a-b, 111a-b, for a given Rl, there is a negotiation introduced between the BPU 110, 111 and the RU 115. The RU 115 collects, such as receives, all the requests from each BPU 110, 111 and their BB applications 110a-b, 111a-b. The negotiation is happening in a “negotiation window”. The start of the negotiation window is known by the BB applications 110a-b, 111a-b on the BPU 110, 111 and the RU 115, as shown in Figure 9. As may be seen in Figure 9, resources negotiated during the negotiation window, is negotiated for a future Rl.

The one or more BB applications, such as the BB application 110a-b, 111a-b, running on the BPU 110, 111 , measures the ongoing traffic per cell and/or sector carrier to predict the resource needs from the RU 115. The prediction is for a future Rl. At the time the negotiation happens, the BB application, or the scheduler in the BB application, sends a resource request to the RU 115 reflecting the predicted needs. Alternatively, the BB application provides the request to the BPU and the BPU sends the resource request to the RU 115. This way the BB application may react to incoming “traffic bursts” and request for more resources for those cells and/or sector carriers where the bursts are happening.

The resources being requested from BB application may typically be one or more of:

- Number of PRBs needed,

- number of layers, e.g., MIMO layers, needed, - number of scheduling entities per Transmission Timing Interval (TTI), such as number of transmissions per slot,

The RU 115, or the resource handler on the Rll 115, then receives all requests from all connected BB applications 110a-b, 111 a-b in the one or more BPUs HO, 111 , and then decides how much of the available resources on the Rll 115 that each BB application 110a-b, 111a-b may use. In other words, the Rll 115 allocates resources to the one or more BB applications 110a-b, 111a-b, comprised in the one or more BPUs 110, 111 based on the respective received resource requests. An example workflow of a BB application, or BB scheduler, for each Rl can be seen in the Figure 10, and an example of the resource negotiations in the Rll 115 may be seen in the Figure 11. The Rll 115, or Rll 115 resource handler, needs to get requests, such as resource requests, from all the BPUs 110, 111 and/or BB applications 110a-b, 111 a-b, before deciding how to handle the resources. Figure 12 shows a combined flow chart, of Figure 10 and Figure 11 , with interaction between the applications in the BPU and the RU 115 during an Rl. As may be seen, the scheduling in the BB applications may continue in the n Rl in parallel with the resource negotiations with the RU 115 for the n+1 Rl.

An example of resource sharing using the proposed dynamic resource allocation negotiation is shown in Figure 13. The example shows how RU resources are allocated to the BB applications per Rl.

In the beginning all BB applications have very low or no traffic to schedule. Then BB appU starts to get a high loaded traffic situation to handle. Therefore, it starts to request a lot of RU resources. Since the other two BB applications are still in low demand for RU resources, the BB Appl 1 can get a lot of RU resources from the RU Resource handler which makes it possible for BB Appl 1 to handle the increased traffic in the best possible way.

Figure 14 shows an example of arrangement in the RU 115.

The RU 115 may comprise an input and output interface 1400 configured to communicate with each other. The input and output interface 1400 may comprise a receiver, e.g. wired and/or wireless, (not shown) and a transmitter, e.g. wired and/or wireless, (not shown). The RU 115 is configured to handle dynamic resources allocation in the wireless communications network 100. The Rll 115 is adapted to be associated to one or more BPUs 110, 111. Each BPU 110, 111 is adapted to comprise one or more BB applications 110a-b, 111a-b for which the resources are to be allocated.

The Rll 115 receives respective resource requests from the one or more BPUs 110, 111. The resources are adapted to be requested for a future Rl.

The RU 115 dynamically allocates, based on the respective request, resources to the one or more BB applications 110a-b, 111a-b adapted to be comprised in the respective one or more BPUs 110, 111 for the future Rl .

The RU 115 sends a resource grant message to the one or more BPUs 110, 111. The message is adapted to indicate the allocated resources.

In some embodiments, the future Rl is adapted to be immediately subsequent to a current Rl.

In some embodiments, the requested resources are adapted to comprise any one or more out of:

- MIMO type, e.g., Single User MIMO (SU-MIMO) or Multiuser MIMO (MU-MIMO), beamforming scheme, number of antenna streams to be used for a transmission, e.g., a maximum and/or minimum number of antenna streams, number of transmissions per slot, transmission timing within the Rl, transmission power, e.g., for DL physical channels, modulation coding scheme (MOS) to be used for a transmission, e.g., a highest and/or lowest MOS allowed, number of Demodulation Reference Signal (DMRS) symbols to be used for a transmission, e.g., maximum number of DMRS symbols, and In some embodiments, to allocate the resources is adapted to comprise to determine the resources to be allocated to the respective BB applications 110a-b, 111a-b, taking available resources in the Rll 115 into account.

In some embodiments, the resources are adapted to be implicitly or explicitly indicated in the respective resource request.

In some embodiments, implicitly indicated resources is adapted to be indicated by any one out of:

- a bitmap, or

- an index.

In some embodiments, an Rl is adapted to be defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1.

In some embodiments, to dynamically allocate the resources is adapted to comprises to repeatedly, during each Rl, perform the steps of receive, allocate and send.

In some embodiments, the requested resources are adapted to be radio resources.

The embodiments herein may be implemented through a respective processor or one or more processors, such as at least one processor 1410 of a processing circuitry in the Rll 115 depicted in Figure 14, 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 a data carrier carrying computer program code for performing the embodiments herein when being loaded into the Rll 115. 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 and downloaded to the Rll 115.

The Rll 115 may further comprise respective a memory 1420 comprising one or more memory units. The memory 1420 comprises instructions executable by the processor 1410 in the Rll 115. The memory 1420 is arranged to be used to store instructions, data, configurations, identifiers, indications, notifications, resources, allocations, tables, predictions, data traffic loads and applications to perform the methods herein when being executed in the RU 115.

In some embodiments, a computer program 1430 comprises instructions, which when executed by the at least one processor 1410, cause the at least one processor 1410 of the Rll 115 to perform the actions above.

In some embodiments, a respective carrier 1440 comprises the respective computer program 1430, wherein the carrier 1430 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

Those skilled in the art will also appreciate that the functional modules in the Rll 115, described below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the Rll 115, that when executed by the respective one or more processors such as the at least one processor 1410 described above cause the respective at least one processor 1410 to perform actions according to any of the actions above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

Figure 15 shows an example of arrangement in the BPU 110.

The BPU 110 may comprise an input and output interface 1500 configured to communicate with each other. The input and output interface 1500 may comprise a receiver, e.g. wired and/or wireless, (not shown) and a transmitter, e.g. wired and/or wireless, (not shown).

The BPU 110 is configured to assist the RU 115 to dynamically allocate resource in the wireless communications network 100. The BPU 110 is adapted to comprise one or more BB applications 110a-b for which the resources are adapted to be allocated. The BPU 110 is adapted to be associated to the Rll 115.

The BPU 110 measured a current data traffic load for the respective BB applications 110a-b.

The BPU 110 predicts resources to be used by the respective one or more BB applications 110a-b in a future Rl.

The BPU 110 sends a resource request to the RU 115 based on the predicted resources. The resources are adapted to be requested for the future Rl.

The BPU 110 receives a resource grant message from the RU 115. The message is adapted to indicate resources allocated to the one or more BB applications 110a-b.

- MIMO type, e.g., Single User MIMO (SU-MIMO) or Multiuser MIMO (MU-MIMO), beamforming scheme, number of antenna streams to be used for a transmission, e.g., a maximum and/or minimum number of antenna streams, number of transmissions per slot, transmission timing within the Rl, transmission power, e.g., for DL physical channels, modulation coding scheme (MOS) to be used for a transmission, e.g., a highest and/or lowest MOS allowed, number of Demodulation Reference Signal (DM RS) symbols to be used for a transmission, e.g., maximum number of DMRS symbols, and

In some embodiments, the resources are adapted to be implicitly or explicitly indicated in the resource request.

In some embodiments, implicitly indicated resources is adapted to be indicated by any one out of: - a bitmap, or

- an index.

In some embodiments, an Rl is adapted to be defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1

In some embodiments, the requested resources are adapted to be radio resources.

In some embodiments, the BPU 110 further being configured to: schedule the allocated resource to the one or more BB applications 110a-b according to the received resource grant message.

In some embodiments, the BPU 110 is further configured to repeatedly, during each Rl, perform the steps of measure, predict, send, receive, and optionally schedule.

The embodiments herein may be implemented through a respective processor or one or more processors, such as at least one processor 1510 of a processing circuitry in the BPU 110 depicted in Figure 15, 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 a data carrier carrying computer program code for performing the embodiments herein when being loaded into the BPU 110. 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 and downloaded to the BPU 110.

The BPU 110 may further comprise respective a memory 1520 comprising one or more memory units. The memory 1520 comprises instructions executable by the processor 1510 in the BPU 110.

The memory 1520 is arranged to be used to store instructions, data, configurations, identifiers, indications, notifications, resources, allocations, tables, predictions, data traffic loads and applications to perform the methods herein when being executed in the BPU 110. In some embodiments, a computer program 1530 comprises instructions, which when executed by the at least one processor 1510, cause the at least one processor 1510 of the BPU 110 to perform the actions above.

In some embodiments, a respective carrier 1540 comprises the respective computer program 1530, wherein the carrier 1530 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

Those skilled in the art will also appreciate that the functional modules in the BPU 110, described below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the BPU 110, that when executed by the respective one or more processors such as the at least one processor 1510 described above cause the respective at least one processor 1510 to perform actions according to any of the actions above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

Further Extensions and Variations

With reference to Figure 16, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, which comprises an access network 3211 , such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, e.g. the RU 115 and the one or more BPUs 110, 110, such as AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network 3214 over a wired or wireless connection 3215. A first user equipment (UE) and/or a Non-AP STA 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 and/or a Non-AP STA in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291 , 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud- implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221, 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).

The communication system of Figure 16 as a whole enables connectivity between one of the connected UEs 3291 , 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291 , 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211 , the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Figure 17. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to setup and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311 , which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Figure 17) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Figure 17) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to setup and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, applicationspecific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331, which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides. It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Figure 17 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291 , 3292 of Figure 16, respectively. This is to say, the inner workings of these entities may be as shown in Figure 17 and independently, the surrounding network topology may be that of Figure 16.

In Figure 17, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the use equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the [select the applicable RAN effect: data rate, latency, power consumption] and thereby provide benefits such as [select the applicable corresponding effect on the OTT service: reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime],

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311 , 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Figure 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 16 and Figure 17. For simplicity of the present disclosure, only drawing references to Figure 18 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional substep 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 3440, the UE executes a client application associated with the host application executed by the host computer.

Figure 19 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 16 and Figure 17. For simplicity of the present disclosure, only drawing references to Figure 19 will be included in this section. In a first step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 3530, the UE receives the user data carried in the transmission.

Figure 20 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 16 and Figure 17. For simplicity of the present disclosure, only drawing references to Figure 20 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally, or alternatively, in an optional second step 3620, the UE provides user data. In an optional substep 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional substep 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer. In a fourth step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Figure 21 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 16 and Figure 17. For simplicity of the present disclosure, only drawing references to Figure 21 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.

In some embodiments, the telecommunication network 3210 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 3210 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 3210, including one or more network nodes QQ110 and/or core network nodes QQ108.

Examples of an ORAN network node include an open radio unit (0-Rll), an open distributed unit (0-Dll), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near- real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1 , W1 , E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112 or 3291) to the core network 3214 over one or more wireless connections.

When using the word "comprise" or “comprising” it shall be interpreted as nonlimiting, i.e. meaning "consist at least of". The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.

Claims

1. A method performed by a Radio Unit, RU, (115) for handling dynamic resources allocation in a wireless communications network (100), wherein the RU (115) is associated to one or more Baseband Processing Units, BPU, (110, 111), wherein each BPU (110, 111) comprises one or more Baseband, BB, applications (110a-b, 111a-b) for which the resources are to be allocated, the method comprising: receiving (401) respective resource requests from the one or more BPUs (110, 111), wherein the resources are requested for a future Resource Interval, Rl, dynamically allocating (402), based on the respective request, resources to the one or more BB applications (110a-b, 111 a-b) comprised in the respective one or more BPUs (110, 111), for the future Rl, and sending (403) a resource grant message to the one or more BPUs (110, 111), which message indicates the allocated resources.

2. The method according to claim 1, wherein the future Rl is immediately subsequent to a current Rl.

3. The method according to the any of claims 1-2, wherein the requested resources comprise any one or more out of:

- Physical Resource Blocks, PRB,

- radio layers,

- transmissions per slot, and

- transmission power.

4. The method according to any of claims 1-3, wherein allocating (402) the resources comprises determining the resources to be allocated to the respective BB applications (110a-b, 111a-b), taking available resources in the RU (115) into account.

5. The method according to any of claims 1-4, wherein the resources are implicitly or explicitly indicated in the respective resource request.

6. The method according to claim 5, wherein implicitly indicated resources is indicated by any one out of:

- a bitmap, or - an index.

7. The method according to any of claims 1-6, wherein an Rl is defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1.

8. The method according to any of claims 1-7, wherein dynamically allocating (302) the resources comprises repeatedly, during each Rl, performing the steps of receiving (401), allocating (402) and sending (403).

9. The method according to any of claims 1-8, wherein the requested resources are radio resources.

10. A computer program (1430) comprising instructions, which when executed by a processor (1410), causes the processor (1410) to perform actions according to any of the claims 1-9.

11. A carrier (1440) comprising the computer program (1430) of claim 10, wherein the carrier (1440) is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer- readable storage medium.

12. A method performed by a Baseband Processing Unit, BPU, (110) for assisting a Radio Unit, RU, (115) in dynamically allocating resource in a wireless communications network (100), wherein the BPU (110) comprises one or more Baseband, BB, applications (110a-b) for which the resources are to be allocated, wherein the BPU (110) is associated to the RU 115, the method comprising: measuring (501) a current data traffic load for the respective BB applications (110a-b), predicting (502) resources to be used by the respective one or more BB applications (110a-b) in a future Resource Interval, Rl, sending (503) a resource request to the RU 115 based on the predicted resources, wherein the resources are requested for the future Rl, and receiving (504) a resource grant message from the RU (115), which message indicates resources allocated to the one or more BB applications (110a-b).

13. The method according to claim 12, wherein the future Rl is immediately subsequent to a current Rl.

14. The method according to the any of claims 12-13, wherein the requested resources comprise any one or more out of:

- Physical Resource Blocks, PRB,

- radio layers,

- transmissions per slot,

- transmission power,

15. The method according to any of claims 12-14, wherein the resources are implicitly or explicitly indicated in the resource request.

16. The method according to claim 15, wherein implicitly indicated resources is indicated by any one out of:

- a bitmap, or

- an index.

17. The method according to any of claims 12-16, wherein an Rl is defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1

18. The method according to any of claims 12-17, wherein the requested resources are radio resources.

19. The method according any of claims 12-18, the method further comprising: scheduling (505) the allocated resource to the one or more BB applications (110a- b) according to the received resource grant message.

20. The method according to any of claims 12-19, wherein the method comprises repeatedly, during each Rl, performing the steps of measuring (501), predicting (502), sending (503), receiving (504), and optionally scheduling (505).

21. A computer program (1530) comprising instructions, which when executed by a processor (1510), causes the processor (1510) to perform actions according to any of the claims 12-20.

22. A carrier (1540) comprising the computer program (1530) of claim 21, wherein the carrier (1540) is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer- readable storage medium.

23. A Radio Unit, RU, (115) configured to handle dynamic resources allocation in a wireless communications network (100), wherein the RU (115) is adapted to be associated to one or more Baseband Processing Units, BPU, (110, 111), wherein each BPU (110, 111) is adapted to comprise one or more Baseband, BB, applications (110a-b, 111a-b) for which the resources are to be allocated, the RU (115) is further configured to: receive respective resource requests from the one or more BPUs (110, 111), wherein the resources are adapted to be requested for a future Resource Interval, Rl, dynamically allocate, based on the respective request, resources to the one or more BB applications (110a-b, 111a-b) adapted to be comprised in the respective one or more BPUs (110, 111), for the future Rl, and send a resource grant message to the one or more BPUs (110, 111), which message is adapted to indicate the allocated resources.

24. The RU (115) according to claim 23, wherein the future Rl is adapted to be immediately subsequent to a current Rl.

25. The RU (115) according to the any of claims 23-24, wherein the requested resources are adapted to comprise any one or more out of:

- Physical Resource Blocks, PRB,

- radio layers,

- transmissions per slot, and

- transmission power.

26. The RU (115) according to any of claims 23-25, wherein to allocate the resources is adapted to comprise to determine the resources to be allocated to the respective BB applications (110a-b, 111a-b), taking available resources in the RU (115) into account.

27. The RU (115) according to any of claims 23-26, wherein the resources are adapted to be implicitly or explicitly indicated in the respective resource request.

28. The RU (115) according to claim 27, wherein implicitly indicated resources is adapted to be indicated by any one out of:

- a bitmap, or

- an index.

29. The Rll (115) according to any of claims 23-28, wherein an Rl is adapted to be defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1.

30. The Rll (115) according to any of claims 23-29, wherein to dynamically allocate the resources is adapted to comprises to repeatedly, during each Rl, perform the steps of receive, allocate and send.

31. The Rll (115) according to any of claims 23-30, wherein the requested resources are adapted to be radio resources.

32. A Baseband Processing Unit, BPU, (110) configured to assist a Radio Unit, RU, (115) to dynamically allocate resource in a wireless communications network (100), wherein the BPU (110) is adapted to comprise one or more Baseband, BB, applications (110a-b) for which the resources are adapted to be allocated, wherein the BPU (110) is adapted to be associated to the RU 115, the BPU (110) is further configured to: measure a current data traffic load for the respective BB applications (110a-b), predict resources to be used by the respective one or more BB applications (110a- b) in a future Resource Interval, Rl, send a resource request to the RU (115) based on the predicted resources, wherein the resources are adapted to be requested for the future Rl, and receive a resource grant message from the RU (115), which message is adapted to indicate resources allocated to the one or more BB applications (110a-b).

33. The BPU (110) according to claim 32, wherein the future Rl is adapted to be immediately subsequent to a current Rl.

34. The BPU (110) according to the any of claims 32-33, wherein the requested resources are adapted to comprise any one or more out of:

- Physical Resource Blocks, PRB, - radio layers,

- transmissions per slot,

- transmission power,

35. The BPU (110) according to any of claims 32-34, wherein the resources are adapted to be implicitly or explicitly indicated in the resource request.

36. The BPU (110) according to claim 35, wherein implicitly indicated resources is adapted to be indicated by any one out of:

- a bitmap, or

- an index.

37. The BPU (110) according to any of claims 32-36, wherein an Rl is adapted to be defined as K*X, wherein X = length of a radio frame and wherein K >= 1 or 0 < K < 1

38. The BPU (110) according to any of claims 32-37, wherein the requested resources are adapted to be radio resources.

39. The BPU (110) according any of claims 32-38, the BPU (110) further being configured to: schedule the allocated resource to the one or more BB applications (110a-b) according to the received resource grant message.

40. The BPU (110) according to any of claims 32-39, wherein the BPU (110) is further configured to repeatedly, during each Rl, perform the steps of measure, predict, send, receive, and optionally schedule.