A method and apparatuses for providing grant-based scheduling

Abstract

Embodiments described herein relate to a method and apparatuses for grant-based scheduling of frequency resource units to one or more user equipments. A method comprises receiving (201) a first scheduling request, SR, from a first User Equipment, UE; responsive to receiving the first SR, selecting (202) to allocate frequency resource units, FRUs, of a first uplink time-based transmission unit, UTTU, to the first UE; determining (203) a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE; and transmitting (204), to the first UE, an uplink grant for transmission using the first number of FRUs.

Description

[0001]A METHOD AND APPARATUSES FOR PROVIDING GRANT-BASED SCHEDULING Technical Field Embodiments described herein relate to grant-based scheduling of frequency resource units to one or more user equipments. Background In wireless communication systems such as fifth generation (5G) New Radio (NR), there are two types of uplink transmissions from a user equipment (UE): grant-based transmissions and grant-less transmissions. In grant-based transmissions, a UE that has data to transmit uses a Scheduling Request (SR) procedure to request resources for a new uplink data transmission. In grant-less transmissions, resources for uplink (UL) Physical Uplink Shared Channel (PUSCH) transmissions are pre-allocated (reserved) and a UE that has data to transmit uses the first available reserved resources to transmit the data. Grant-less transmissions can be used to reduce the latency in the system, since UEs do not have to wait for the network to allocate resources for the transmission, but they are inefficient from a resource usage perspective compared to grant-based transmission. Figure 1 is a flow chart illustrating a grant-based transmission procedure for the transmission of data from a UE in the uplink. At step 101, data belonging to a specific logical channel (LC) arrives for transmission within the UE buffer. Thus, the UE has data to send in the uplink. At step 102, the Medium Access Control (MAC) layer in the UE triggers the physical (PHY) layer to send an SR using Physical Uplink Control Channel (PUCCH) resources that have been configured by the gNodeB (gNB) for the UE. The UE sends an SR using PUCCH resources in this manner whenever new data arrives at the UE buffer and there is no uplink grant already allocated for the UE. The gNB configures the PUCCH resources for SR transmission for each UE, and this resource configuration comprises various parameters related to, for example, the period between SR resources, an offset relative to a reference slot number, and a maximum number of times an SR can be sent. Radio Resource Control (RRC) connection setup or RRC reconfiguration request messages are used to configure the scheduling request related parameters. The PUCCH resources configured for SR transmission may be associated with a specific LC or a group of LCs. Any PUCCH format can be used to send an SR, i.e., any of formats 0, 1, 2, 3 and 4, although typically SR PUCCH resources are configured using either PUCCH format 0 or PUCCH format 1. Other PUCCH formats can be used when PUCCH transmissions coincide. For example, an SR transmission using PUCCH format 0 may coincide with a CSI Reporting transmission using PUCCH format 3. In that case, both the SR and the CSI Report can be transmitted on the same PUCCH format 3 resource. The MAC layer is controlling the SR and the information element (IE) MAC- CellGroupConfig is used to configure MAC parameters for a cell group. MAC-CellGroupConfig ::= SEQUENCE { drx-Config } OPTIONAL, -- Need M schedulingRequestConfig bsr-Config tag-Config phr-Config skipUplinkTxDynamic BOOLEAN, ... } IE SchedulingRequestConfig is used to configure the parameters, for the dedicated scheduling request (SR) resources. RRC Parameters SchedulingRequestConfig ::= SEQUENCE { schedulingRequestToAddModList SEQUENCE (SIZE (1..maxNrofSR- ConfigPerCellGroup)) OF SchedulingRequestToAddMod OPTIONAL, schedulingRequestToReleaseList SEQUENCE (SIZE (1..maxNrofSR- ConfigPerCellGroup)) OF SchedulingRequestId OPTIONAL -- Need N } SchedulingRequestToAddMod ::= SEQUENCE { schedulingRequestId SchedulingRequestId, sr-ProhibitTimer ENUMERATED {ms1, ms2, ms4, ms8, ms16, ms32, ms64, ms128} sr-TransMax ENUMERATED {n4, n8, n16, n32, n64, spare3, spare2, spare1} } schedulingRequestId : Used to modify a SR configuration and to indicate, in LogicalChannelConfig, the SR configuration to which a logical channel is mapped, and to indicate, in SchedulingRequestresourceConfig, the SR configuration for which a scheduling request resource is used. - The IE "SchedulingRequestId" is used to identify a Scheduling Request instance in the MAC layer. SchedulingRequestId ::= INTEGER (0..7) The a pointer towards an additional set of parameters associated with the Scheduling Request resources. Each SR configuration corresponds to one or more logical channels. Each logical channel may be mapped to zero or one SR configuration, which is configured by RRC. The RRC layer configures the following parameters for the scheduling request procedure: sr-ProhibitTimer defines the minimum time between consecutive SRs, i.e. the UE has to wait ProhitnitTimer amount of time before sending another SR. This is to avoid overloading UL resources with very fast SR requests from UEs. sr-TransMax specifies the maximum number of SRs a UE can send to a gNB. If the UE has sent maximum number of SRs and has not received UL resources for data transmission, the UE releases its PUCCH resources and SRS resources and initiates the RACH procedure. SchedulingRequestResourceConfig ::= SEQUENCE { schedulingRequestResourceId SchedulingRequestResourceId, schedulingRequestID SchedulingRequestId, periodicityAndOffset CHOICE { sym2 NULL, sym6or7 NULL, sl1 NULL, -- Recurs in every slot sl2 INTEGER (0..1), sl4 INTEGER (0..3), sl5 INTEGER (0..4), sl8 INTEGER (0..7), sl10 INTEGER (0..9), sl16 INTEGER (0..15), sl20 INTEGER (0..19), sl40 INTEGER (0..39), sl80 INTEGER (0..79), sl160 INTEGER (0..159), sl320 INTEGER (0..319), sl640 INTEGER (0..639) } OPTIONAL, -- Need M resource PUCCH-ResourceId OPTIONAL -- Need M } SchedulingRequestResourceConfig-v1610 ::= SEQUENCE { phy-PriorityIndex-r16 ENUMERATED {p0, p1} OPTIONAL, -- Need M ... } periodicityAndOffset : SR periodicity and offset in number of symbols or slots (3GPP NR; Physical layer procedures for control, TS 38.213, v. 17.5.0, section 9.2.4) The following periodicities may be configured depending on the chosen subcarrier spacing: SCS = 15 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 5sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl SCS = 30 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl, 160sl SCS = 60 kHz: 2sym, 7sym / 6sym, 1sl, 2sl, 4sl, 8sl, 16sl, 20sl, 40sl, 80sl, 160sl, 320sl SCS = 120 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 16sl, 40sl, 80sl, 160sl, 320sl, 640sl sym6or7 corresponds to 6 symbols if extended cyclic prefix and a SCS of 60 kHz are configured, otherwise it corresponds to 7 symbols. For periodicities 2sym, 7sym and sl1 the UE assumes an offset of 0 slots. phy-PriorityIndex : Indicates whether this scheduling request resource is high or low priority in PHY prioritization / multiplexing handling. Value p0 indicates low priority and value p1 indicates high priority. The UE can be provided, by phy-PriorityIndex in SchedulingRequestResourceConfig, a priority index 0 or a priority index 1 for the SR. If the UE is not provided a priority index for SR, the priority index is 0 (3GPP NR; Physical layer procedures for control,TS 38.213, v.17.5.0, section 9.2.4). resource : ID of the PUCCH resource in which the UE shall send the scheduling request. The actual PUCCH-Resource is configured in PUCCH-Config of the same UL BWP and serving cell as this SchedulingRequestResourceConfig. The network configures a PUCCH-Resource of PUCCH-format0 or PUCCH-format1 schedulingRequestID : The ID of the SchedulingRequestConfig that uses this scheduling request resource. LogicalChannelConfig ::= SEQUENCE { ul-SpecificParameters SEQUENCE { priority INTEGER (1..16), prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512, kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity}, bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000, spare7, spare6, spare5, spare4, spare3,spare2, spare1}, allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex OPTIONAL, allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1} configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R logicalChannelSR-Mask BOOLEAN, logicalChannelSR-DelayTimerApplied BOOLEAN, ..., bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R } OPTIONAL, -- Cond UL ... } Buffer Status Reports are sent per Logical Channel Group (LCG) rather than per LC, although it is possible for an LCG to include only a single LC. Typically, the LCs with similar QoS and priority requirements are associated with the same LCG. The gNB can deduce information about the LC or LCG from the SR, and the gNB may prioritise the UEs request based on this information. Once the gNB has received the SR, the gNB allocates, to the UE, uplink resources on the PUSCH. For example, the uplink resources may be frequency resource blocks (RBs) of an UL slot (where one UL slot may be 0.5 ms long). The uplink resources are allocated assuming a fixed payload size corresponding to size of the Buffer Status Report (BSR) of the UE. Typically, this can be X bits, for example X can be smaller than 1000 bits. It will be appreciated that different UEs may be associated with different fixed payload sizes. This fixed pay load size may be assumed by the gNB because the gNB does not yet have information relating to how much data is in the buffer at the UE, and therefore the gNB is not able to provide uplink resources based how much data the UE needs to send. Thus, at step 103, the gNB sends a first uplink grant to the UE for the number of resources required for the UE to transmit a BSR. The uplink grant is sent using a Downlink Control Information (DCI) format 0_0 / 0_1 message on a Physical Downlink Control Channel (PDCCH) transmission. RRC Parameters for BSR MAC-CellGroupConfig ::= SEQUENCE { drx-Config SetupRelease { DRX-Config } OPTIONAL, -- Need M schedulingRequestConfig SchedulingRequestConfig OPTIONAL, -- Need M bsr-Config BSR-Config OPTIONAL, -- Need M tag-Config TAG-Config OPTIONAL, -- Need M phr-Config SetupRelease { PHR-Config } OPTIONAL, -- Need M skipUplinkTxDynamic BOOLEAN, ..., [[ csi-Mask-v1530 BOOLEAN OPTIONAL , -- Need M dataInactivityTimer-v1530 SetupRelease { DataInactivityTimer } OPTIONAL -- Need PCellOnly ]] } BSR-Config ::= SEQUENCE { periodicBSR-Timer ENUMERATED { sf1, sf5, sf10, sf16, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf320, sf640, sf1280, sf2560, infinity }, retxBSR-Timer ENUMERATED { sf10, sf20, sf40, sf80, sf160, sf320, sf640, sf1280, sf2560,sf5120, sf10240, spare5, spare4, spare3, spare2, spare1}, logicalChannelSR-DelayTimer ENUMERATED { sf20, sf40, sf64, sf128, sf512, sf1024, sf2560, spare1} OPTIONAL, -- Need R ... At step 104, the UE uses the resources of the uplink grant to send a BSR to the gNB, which provides the gNB with information regarding the volume of data that the UE is waiting to transmit. Once the BSR is received at the gNB, the gNB sends, at step 105, a second uplink grant to the UE with enough PUSCH resources to send the actual data. The one or more grants are sent on the PDCCH channel using DCI formats 0_0 or 0_1. At step 106, the UE sends the data on the PUSCH resources of the uplink grant. Summary As set out above, a UE needs at least three UL time slots to send data to the network (e.g., to a gNB) using grant-based transmissions: one slot for transmission of the SR, one slot for transmission of the BSR, and at least one slot for transmission of the data. This can be inefficient from an energy efficiency perspective, especially when the UE has only a small amount of data to send to a gNB. Furthermore, the occupancy of available uplink PUSCH resources is low and therefore there are a significant number of RBs unoccupied in UL slots. In some networks, it has been observed that in 80% of UL slots, the PUSCH RB occupancy is less than 40%. Therefore, there is a need to make better use of these spare RB resources for PUSCH in the UL. Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. According to some embodiments there is provided a method performed by a network node for grant-based scheduling of frequency resource units to one or more user equipments. The method comprises receiving a first scheduling request, SR, from a first User Equipment, UE; responsive to receiving the first SR, selecting to allocate frequency resource units, FRUs, of a first uplink time-based transmission unit, UTTU, to the first UE; determining a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE; and transmitting, to the first UE, an uplink grant for transmission using the first number of FRUs. According to some embodiments there is provided a network node for grant-based scheduling of frequency resource units to one or more user equipments. The network node is adapted to: receive a first scheduling request, SR, from a first User Equipment, UE; responsive to receiving the first SR, select (202) to allocate frequency resource units, FRUs, of a first uplink time-based transmission unit, UTTU, to the first UE; determine a first number of FRUs to allocate to the first UE based on whether there would be un- allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE; and transmit, to the first UE, an uplink grant for transmission using the first number of FRUs. According to some embodiments there is provided a network node for grant-based scheduling of frequency resource units to one or more user equipments. The network node comprises a processor and a memory, the memory containing instructions executable by the processor whereby the network node is operative to: receive a first scheduling request, SR, from a first User Equipment, UE; responsive to receiving the first SR, select to allocate frequency resource units, FRUs, of a first uplink time-based transmission unit, UTTU, to the first UE; determine a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE; and transmit, to the first UE, an uplink grant for transmission using the first number of FRUs. According to some embodiments there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method as described above. According to some embodiments there is provided a computer-readable medium comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method as described above. According to some embodiments there is provided a carrier containing the computer program described above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer-readable medium. Thus, the techniques disclosed herein improve PUSCH resource utilization by allocating resources more efficiently in response to an SR from a UE. When there are unoccupied UL RBs during an UL slot, more resources are allocated to the UE in response to the SR. As such, the UE can transmit any small amount of UL data using the resources associated with the first grant in response to an SR. Thereby, for small amounts of UL data, avoiding the steps 104, 105 and 106 in Fig.1. The techniques disclosed herein also improve the energy efficiency of the network. By using UL resources more efficiently, there is a larger number of UL slots in which there is no UL data to be received from any UE. During these unoccupied (empty) time- frequency resources (UL slots), the hardware components in the receiver part of the network node can be turned off or put in low-power mode to reduce the power consumption. For example, hardware components in the receiver (Rx) chain, such as, low-noise amplifiers, Rx application-specific integrated circuit (ASIC) and the uplink digital front end (DFE), can be placed in low-power mode, e.g., in response to time- frequency resource information from the scheduler. An example of such an energy efficiency feature that may be employed is MicroSleep Rx (MSRx), in which some of the hardware components of a network node are switched off or put in low-power configuration mode when there is no data to be received from any UE in the uplink. These energy saving features are advantageously applicable in all downlink / uplink load conditions, but the gains are particularly significant in low to medium load conditions where there are more unoccupied time-frequency resources. The gains achieved by implementing these energy saving features can also be significant in Frequency Division Duplexing (FDD) radios. Brief Description of the Drawings For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: Fig.1 is a flow chart illustrating a grant-based transmission procedure; Fig.2 is a flow chart illustrating a method in accordance with some embodiments; Fig.3 is a flow chart illustrating a method in accordance with some embodiments; Fig.4 is a flow chart illustrating a method in accordance with some embodiments; Fig. 5 shows an example of a communication system in accordance with some embodiments; Fig.6 shows a network node in accordance with some embodiments; and Fig.7 shows a network node in accordance with some embodiments. Detailed Description Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description. The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general-purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and / or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. As used herein, a frequency resource unit (FRU) is a unit of frequency and time resource in a network. A frequency resource unit is a fixed-size channel that may be allocated to a user to transmit or receive data. It will be understood by the skilled person that a frequency resource unit may have a finite width in both frequency and time. A frequency resource unit may also be referred to as a frequency-time resource unit or a frequency- domain resource unit. In some embodiments, a frequency resource unit may correspond to a resource block, also referred to as a physical resource block (PRB). Each FRU may, for example, have a bandwidth of 180 kHz. Each FRU may comprise 12 subcarriers in the frequency domain, where each subcarrier has a bandwidth of 15 kHz. There may be seven FRUs in a 0.5 ms time period. However, in other embodiments, an FRU may have any other size in frequency and time. Thus, an FRU may comprise any number of subcarriers. As used herein, a time-based transmission unit (TTU) is a unit of time and frequency resource in a network. It will be understood by the skilled person that a TTU has a finite width in both time and frequency. In some embodiments, a TTU may correspond to a slot, e.g., an UL slot. The TTU may be an uplink time-based transmission unit (UTTU). Each TTU may, in some embodiments, have a duration of 0.5 millisecond, which may, for example, be divided into seven symbols. Each TTU may have a bandwidth of 180 kHz, which may be divided into 12 subcarriers each of 15 kHz. As noted above, 12 subcarriers may correspond to one PRB. However, in other embodiments, a TTU may have any other size in time and frequency. Thus, a TTU may comprise any number of symbols. Figure 2 illustrates a method for grant-based scheduling of frequency resource units to one or more user equipments (UEs) according to some embodiments of the present disclosure. The method 200 may be performed by a network node, for example, network node 510A, 510B, network node 600, and network node 700 as described later with reference to Figures 5, 6 and 7 respectively. The method may be implemented, for example, in a base station in a communication network such as a gNB. The method of Figure 2 may be performed by a network node, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. The method 200 of Fig.2 comprises, at step 201, receiving a first scheduling request, SR, from a first UE. The first SR may be received on PUCCH resources. The PUCCH resources may have been configured by the network node for the first UE. The PUCCH resources for the SR transmission may be associated with a specific LC or a LC group. The PUCCH resources may be any one of: format 0, 1, 2, 3 and 4. The method 200 of Fig.2 further comprises, at step 202, responsive to receiving the first SR, selecting to allocate FRUs of a first uplink time-based transmission unit (UTTU) to the first UE. At step 203, the method 200 further comprises determining a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE. The initial allocation of FRUs may comprise an allocation of specific FRUs to one or more UEs. The one or more UEs may be allocated in the initial allocation either FRUs for transmission of a BSR (for example, the first UE would be allocated this), or specific FRUs for transmission of data. If there would be un-allocated FRUs after this initial allocation, then the network node may determine to include some of these un-allocated FRUs in the first number of FRUs allocated to the first UE (i.e., the network node may modify the allocation size for the first UE based on spare FRUs in the UTTU). If there would not be un-allocated FRUs after the initial allocation, then the network node may determine not to modify the initial allocation (in which the first UE is allocated the number of FRUs required for the first UE to send a BSR). Therefore, the determined first number of FRUs to allocate to the first UE may be equal to or larger than the number of FRUs required for the first UE to send a BSR. An example implementation of step 203 according to some embodiments will be described in more detail later with reference to Fig.3. In some embodiments, the step 203 of determining the first number of FRUs to allocate to the first UE is performed responsive to identifying that the first SR is a qualifying SR. Thus, in some embodiments, step 203 is only performed if the first SR is identified as a qualifying SR. It will be appreciated, that if the first SR is not identified as a qualifying SR, step 103 of Fig.1 may be performed instead. The meaning of ‘qualifying SR’ as well as possible techniques for identifying a qualifying SR will be described later with reference to Fig.4. In alternative embodiments, the network node may perform step 203 for all SRs that the network node receives. In some embodiments, the step 203 of determining the first number of FRUs to allocate to the first UE is performed responsive to determining that a load associated with the network node satisfies a criterion. For example, the criterion may be satisfied when the load associated with the network node is below a threshold value. In other words, if the load on the network node is too high, it may not be considered beneficial to perform determination of step 203 as there may be less un-allocated resources available anyway, meaning that the benefits to be derived from performing step 203 are less. Thus, in some embodiments, step 203 is only performed if a load associated with the network node satisfies a criterion. It will be appreciated that if the load associated with the network node does not satisfy the criterion, step 103 of Fig. 1 may be performed instead. The load associated with the network node may comprise an uplink load, such as an uplink physical resource block load, e.g., representing uplink PRB utilization. Alternatively, or in addition, the load associated with the network node may comprise an uplink UE load representative of a number of UEs served by the network node for uplink transmission. Alternatively, or in addition, the load associated with the network node may comprise an uplink buffer load representative of a first buffer load on uplink buffers associated with the network node. Alternatively, or in addition, the load associated with the network node may comprise an indication of the ability of the network node to fulfil Quality of Service (QoS) and / or key performance indicators (KPIs) requirements of communication services based on factors such as latency, throughput and a drop rate of data packets, e.g., in the uplink. At step 204, the method 200 further comprises transmitting, to the first UE, an uplink grant for transmission using the first number of FRUs. In some embodiments, step 204 may further comprise transmitting an uplink grant to each UE that sent an SR and has been allocated one or more FRUs in the first UTTU. The method 200 of Fig. 2 may further comprise, after transmitting the uplink grant, receiving, from the first UE, data on at least one of the first number of FRUs allocated to the first UE. Advantageously, if the network node determined in step 203 to grant additional resources (beyond the fixed payload size assumed in existing methods, e.g., in step 103 of Fig.1) within the first grant after receiving the first SR, then the first UE may be able to finish the transmission of its UL data within the first transmission after sending the first SR, rather than sending only the BSR (as would occur in the method of Figure 1). This can result in more efficient UL resource usage. Furthermore, such efficient UL resource usage may create blank UL slots in which the MSRx feature may then be active, thus providing energy savings. Figure 3 is a flow chart illustrating an example implementation of step 203 of method 200 which was described with respect to Fig.2. As described above, in step 203 of method 200, the network node determines the first number of FRUs based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to one or more UEs comprising the first UE. In some embodiments, step 203 comprises performing steps 301 to 304 of Figure 3. At step 301 of Fig. 3, the network node performs the initial allocation by allocating an allocated number of FRUs comprising respective initial numbers of FRUs to the one or more UEs comprising the first UE. In this initial allocation, specific FRUs within the first UTTU are allocated to the one or more UEs. The respective initial numbers of FRUs may be a respective number of FRUs required for a UE to send a buffer status report or may be a respective number of FRUs for a UE to send data. The initial allocation of FRUs may therefore be allocating FRUs to UEs that are at various stages in the procedure. For example, some UEs may have just sent the SR and the initial allocation to those UEs may comprise the respective number of FRUs required for those UEs to transmit their BSRs. However other UEs may have already sent their BSRs, and the initial allocation in the UTTU for those UEs may be for actual data transmission. In other words, the initial number of FRUs allocated to the first UE for an uplink grant as a response to an SR sent by the first UE may be the number of FRUs required by the first UE to send only it's BSR to the network node. Thus, the initial allocation may correspond to the allocation that would be made to the first UE under existing methods. However, it will be understood that performing the initial allocation at step 301 does not mean that the network node sends uplink grants according to the initial allocation. Instead, the network node proceeds to step 302. At step 302, the network node determines whether there are un-allocated FRUs in the first UTTU after the initial allocation based on a total number of FRUs in the first UTTU and an allocated number of FRUs in the first UTTU that have been allocated to the one or more UEs. For example, the network node may, responsive to the total number of FRUs being equal to the allocated number of FRUs, determine that there are no un- allocated FRUs in the first UTTU, and responsive to the total number of FRUs being greater than the allocated number of FRUs, determine that there are un-allocated FRUs in the first UTTU. Responsive to the network node determining that there are no un-allocated FRUs in the first UTTU (“no” in Fig.3), the network node may, at step 303, select the respective initial number of FRUs for the first UE as the first number of FRUs. In other words, in step 303 the network node only allocates the initial number of FRUs to the first UE for the uplink grant as a response to the received first SR as there aren’t any un-allocated FRUs available. Responsive to the network node determining that there are un-allocated FRUs in the first UTTU (“yes” in Fig.3), the network node may, at step 304, select a number of the un- allocated FRUs to be allocated to the first UE in addition to the respective initial number of FRUs for the first UE, as a response to the received first SR. Thus, the network node allocates more resources in this instance than would be allocated under existing methods, for example as illustrated in Fig.1. In alternative example implementation of step 203 of method 200, the network node may determine whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to one or more UEs comprising the first UE without performing the initial allocation. In other words, the network node may determine whether there would be un-allocated FRUs in the first UTTU by determining the number of FRUs that would be needed to provide the initial allocation of FRUs, rather than allocating the specific FRUs. To do so, the network node may sum the initial numbers of FRUs for the one or more UEs (without actually allocating specific FRUs to the one or more UEs). The network node may then determine a number of FRUs that would be unallocated if the initial allocation were to be made based on a total number of FRUs in the first UTTU and the number of FRUs that would be needed to provide the initial allocation of FRUs. Responsive to the total number of FRUs being equal to the number of FRUs needed to provide the initial allocation of FRUs, the network node may determine that there are no un-allocated FRUs in the first UTTU. At this point, this example implementation would then continue to step 303 of Fig.3. Responsive to the total number of FRUs being greater than the number of FRUs needed to provide the initial allocation of FRUs, the network node may determine that there are un-allocated FRUs in the first UTTU. At this point, this example implementation would then continue to step 304 of Fig.3. Figure 4 is a flow chart illustrating an example implementation of step 304 of Fig.3. According to some embodiments, selecting the number of the un-allocated FRUs to be allocated to the first UE (step 304) may comprise, at step 401, identifying one or more qualifying SRs comprising the first SR. Here, a qualifying SR is an SR that qualifies to receive additional resource (i.e., additional FRUs) in an UTTU (in this case, the first UTTU). The one or more qualifying SRs may be selected from a set of one or more SRs each received from a UE that has been allocated or selected to be allocated at least one FRU in the first UTTU. The set of one or more SRs may be SRs that the network node has received. Identifying the one or more qualifying SRs in step 401 may comprise the network node selecting each qualifying SR based on one or more characteristics of each SR in the set. The one or more characteristics may comprise one or more of: a logical channel priority associated with the qualifying SR; a priority index (e.g., a phy-priority index) associated with the qualifying SR; a prediction of a logical channel buffer size for a UE that sent the qualifying SR; a relationship between the predicted Logical channel buffer size for the UE that sent the qualifying SR and the un-allocated FRUs in the first UTTU; and a measured uplink signal to interference plus noise power ratio (SINR) for the UE that sent the qualifying SR. A logical channel priority associated with the qualifying SR may be the LC priority of the PUCCH resources on which the qualifying SR is received. A priority index associated with the qualifying SR may be comprised in the qualifying SR. For example, an SR associated with a higher priority logical channel may be more likely to be selected as a qualifying SR than another SR associated with a lower priority logical channel. In some embodiments, all SRs with an LC priority that satisfies a criterion are selected as a qualifying SR, e.g., all SRs with an LC priority above a threshold value. In alternative embodiments, the SR in the set with the highest LC priority is selected as a qualifying SR (e.g., is selected to be allocated additional resource). Then, the SRs may be selected in order of decreasing LC priority, for example, until all the un-allocated FRUs are accounted for (e.g., become or would become allocated). In some embodiments, a SR with a higher priority index may be more likely to be selected as a qualifying SR than another SR with a lower priority index. In some embodiments, all SRs with a priority index that satisfies a criterion are selected as a qualifying SR, e.g., all SRs with a priority index above a threshold value. In alternative embodiments, the SR in the set of one or more SRs with the highest priority index is selected as a qualifying SR (i.e., is selected to be allocated additional resource). Then, the SRs may be selected in order of decreasing priority index, for example, until all the un-allocated FRUs are accounted for (e.g., become or would become allocated). In some embodiments, the qualifying SRs are selected based on a prediction of a logical channel buffer size for the UE that sent the SR. For example, the network node may collect statistics of the data sizes received from the different UEs on different logical channels, and run a prediction algorithm to predict the buffer size of the next packet that will be sent from the UE on a particular logical channel. For example, the SR with the smallest corresponding predicted logical channel buffer size may be selected as a qualifying SR first, and the remaining SRs are selected as qualifying SRs in order of increasing corresponding predicted logical channel buffer size until all the un-allocated FRUs are accounted for (e.g. become or would become allocated). The network node may predict the logical channel buffer size based on previous transmissions. For example, the network node may predict the logical channel buffer size by collecting statistics of the data sizes received from the different UEs, and running a prediction algorithm to predict the buffer size of the next packet that will be transmitted by the UE in the UL.. In some examples, multiple SRs associated with different LCs may be received from a single UE. In such a case, the SR for an LC with the smallest predicted logical channel buffer size may be selected as a qualifying SR. In some embodiments, the qualifying SRs are selected based on a relationship between the predicted logical channel buffer size for the UE that sent the qualifying SR and the un-allocated FRUs in the first UTTU. In these embodiments, the qualifying SRs may be selected such that all of the un-allocated FRUs are used. In some embodiments, the qualifying SRs are selected based on a measured uplink SINR for the UE that sent the qualifying SR. For example, the SR received from the UE with the highest corresponding SINR may be selected as a qualifying SR first, and the remaining SRs are selected as qualifying SRs in order of decreasing SINR of the associated UEs. In some embodiments, a formula for selecting the qualifying SRs may be based on any combination of one or more of the above criteria. For example, the buffer size prediction or SINR may act as a further filter of all SRs in the set that have a corresponding LC priority that satisfies a criterion (e.g., is above a threshold value). Regardless of how the qualifying SRs are selected, the selection of the qualifying SRs allows for prioritising SRs for allocation of extra un-allocated resources based on the characteristics listed in the description of step 401. Selecting the number of the un-allocated FRUs to be allocated to the first UE (step 304 of Fig.3) may further comprise, after identifying the one or more qualifying SRs in step 401, distributing the un-allocated FRUs amongst (the uplink grants for) the one or more UEs that sent the one or more qualifying SRs in step 402 of Fig.4. In some embodiments, the un-allocated FRUs may be distributed amongst the one or more UEs that sent the one or more qualifying SRs such that the un-allocated FRUs are distributed equally amongst (the uplink grants for) the one or more UEs that sent the one or more qualifying SRs. In some embodiments, the un-allocated FRUs are distributed amongst the one or more UEs that sent the one or more qualifying SRs based on one or more characteristics of at least one qualifying SR. The one or more characteristics may comprise any of the characteristics described above with respect to step 401. Thus, the one or more characteristics may comprise one or more of: a logical channel priority associated with the qualifying SR; a priority index associated with the qualifying SR (e.g. phy- PriorityIndex); a prediction of a logical channel buffer size for a UE that sent the qualifying SR; a relationship between the predicted logical channel buffer size for the UE that sent the qualifying SR and the number of un-allocated FRUs in the first UTTU; and a measured uplink SINR for the UE that sent the qualifying SR. For example, in some embodiments, the network node may distribute the un-allocated FRUs such that as many UEs that sent the qualifying SRs as possible are allocated a total number of FRUs equal to the corresponding predictions of logical channel buffer size for the UE that sent the qualifying SR. In some embodiments, the network node may distribute the un-allocated FRUs such that all UEs that sent the qualifying SRs in order of decreasing logical channel priorities (or decreasing priority index) are allocated a total number of FRUs equal to the corresponding predictions of logical channel buffer size, for example, until all the un- allocated RBs are allocated. Thus, by making use of FRUs that would otherwise be unallocated and therefore unused, the techniques disclosed herein improve PUSCH resource utilization. The techniques disclosed herein can result in UTTUs in which there is no UL data to be transmitted by any UE. During these blank UTTUs, hardware components may be turned off or put in low-power mode (e.g., MSRx) at the network node, thereby providing significant energy savings. Figure 5 shows an example of a communication system 500 in accordance with some embodiments. In the example, the communication system 500 includes a telecommunication network 502 that includes an access network 504, such as a radio access network (RAN), and a core network 506, which includes one or more core network nodes 508. The access network 504 includes one or more access network nodes, such as network nodes 510a and 510b (one or more of which may be generally referred to as network nodes 510), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skilled in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 502 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 502 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 502, including one or more network nodes 510 and / or core network nodes 508. It will be appreciated that the network nodes 510 may be configured to perform the method of any of Figures 2, 3 and 4. Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), 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 510 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 512a, 512b (one or both of which may be generally referred to as UEs 512) to the core network 506 over one or more wireless connections. Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 500 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 500 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system. The UEs 512 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 510 and other communication devices. Similarly, the network nodes 510 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 512 and / or with other network nodes or equipment in the telecommunication network 502 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 502. The core network 506 includes one more core network nodes (e.g., core network node 508) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs and / or network nodes, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 508. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF). As a whole, the communication system 500 of Figure 5 enables connectivity between the UEs and network nodes. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. In some examples, the telecommunication network 502 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 502 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 502. For example, the telecommunications network 502 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive IoT services to yet further UEs. In some examples, the UEs 512 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 504. Additionally, a UE may be configured for operating in single- or multi-RAT or multi- standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR- DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio – Dual Connectivity (EN-DC). Figure 6 shows a network node 600 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU). Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi- cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs). The network node 600 includes processing circuitry 602, a memory 604, a communication interface 606, and a power source 608, and / or any other component, or any combination thereof. The network node 600 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 600 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 600 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 604 for different RATs) and some components may be reused (e.g., a same antenna 610 may be shared by different RATs). The network node 600 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 600, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 600. The processing circuitry 602 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 600 components, such as the memory 604, network node 600 functionality. For example, the processing circuitry 602 may be configured to cause the network node 600 to perform the methods as described with reference to any of Figures 2, 3 and 4. In some embodiments, the processing circuitry 602 includes a system on a chip (SOC). In some embodiments, the processing circuitry 602 includes one or more of radio frequency (RF) transceiver circuitry 612 and baseband processing circuitry 614. In some embodiments, the radio frequency (RF) transceiver circuitry 612 and the baseband processing circuitry 614 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 612 and baseband processing circuitry 614 may be on the same chip or set of chips, boards, or units. The memory 604 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read- only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer- executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 602. The memory 604 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 602 and utilized by the network node 600. The memory 604 may be used to store any calculations made by the processing circuitry 602 and / or any data received via the communication interface 606. In some embodiments, the processing circuitry 602 and memory 604 is integrated. The communication interface 606 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 606 comprises port(s) / terminal(s) 616 to send and receive data, for example to and from a network over a wired connection. The communication interface 606 also includes radio front-end circuitry 618 that may be coupled to, or in certain embodiments a part of, the antenna 610. Radio front-end circuitry 618 comprises filters 620 and amplifiers 622. The radio front-end circuitry 618 may be connected to an antenna 610 and processing circuitry 602. The radio front-end circuitry may be configured to condition signals communicated between antenna 610 and processing circuitry 602. The radio front-end circuitry 618 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 618 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 620 and / or amplifiers 622. The radio signal may then be transmitted via the antenna 610. Similarly, when receiving data, the antenna 610 may collect radio signals which are then converted into digital data by the radio front-end circuitry 618. The digital data may be passed to the processing circuitry 602. In other embodiments, the communication interface may comprise different components and / or different combinations of components. In certain alternative embodiments, the network node 600 does not include separate radio front-end circuitry 618, instead, the processing circuitry 602 includes radio front- end circuitry and is connected to the antenna 610. Similarly, in some embodiments, all or some of the RF transceiver circuitry 612 is part of the communication interface 606. In still other embodiments, the communication interface 606 includes one or more ports or terminals 616, the radio front-end circuitry 618, and the RF transceiver circuitry 612, as part of a radio unit (not shown), and the communication interface 606 communicates with the baseband processing circuitry 614, which is part of a digital unit (not shown). The antenna 610 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 610 may be coupled to the radio front- end circuitry 618 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 610 is separate from the network node 600 and connectable to the network node 600 through an interface or port. The antenna 610, communication interface 606, and / or the processing circuitry 602 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 610, the communication interface 606, and / or the processing circuitry 602 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment. The power source 608 provides power to the various components of network node 600 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 608 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 600 with power for performing the functionality described herein. For example, the network node 600 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 608. As a further example, the power source 608 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. Embodiments of the network node 600 may include additional components beyond those shown in Figure 6 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 600 may include user interface equipment to allow input of information into the network node 600 and to allow output of information from the network node 600. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 600. Figure 7 is a block diagram illustrating a network node 700 according to some embodiments. The network node 700 can perform grant-based scheduling of frequency resource units to one or more user equipments. It will be appreciated that the network node 700 may be configured to perform the method of any of Figures 2, 3 and 4. The network node 700 comprises a receiving module 701 configured to receive a first scheduling request from a first User Equipment. The network node 700 comprises a selecting module 702 configured to, responsive to receiving the first SR, select to allocate frequency resource units of a first uplink time- based transmission unit to the first UE. The network node 700 further comprises a determining module 703 configured to determine a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE. The network node 700 further comprises a transmitting module 704 configured to transmit, to the first UE, an uplink grant for transmission using the first number of FRUs. Any of the modules of Fig. 7 may be in communication with each other. The network node 700 may comprise further modules not shown in Fig.7, e.g., for performing any of the steps of Figs.3 and 4. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS 1. A method performed by a network node for grant-based scheduling of frequency resource units, FRUs to one or more user equipments, the method comprising: receiving (201) a first scheduling request, SR, from a first User Equipment, UE; responsive to receiving the first SR, selecting (202) to allocate FRUs of a first uplink time-based transmission unit, UTTU, to the first UE; determining (203) a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE; and transmitting (204), to the first UE, an uplink grant for transmission using the first number of FRUs.

2. The method of claim 1 wherein the first SR is associated with a first logical channel.

3. The method of claim 1 or 2, further comprising determining whether there would be un-allocated FRUs in the first UTTU by: performing the initial allocation by allocating (403) an allocated number of FRUs comprising respective initial numbers of FRUs allocated to the one or more UEs; and determining (404) whether there are un-allocated FRUs in the first UTTU after the initial allocation based on a total number of FRUs in the first UTTU and an allocated number of FRUs in the first UTTU that have been allocated to the one or more UEs.

4. The method of claim 3, wherein the respective initial number of FRUs for the first UEs is a respective number of FRUs required for the first UE to send a buffer status report.

5. The method of claim 3 or 4, wherein determining (404) whether there are un- allocated FRUs comprises: responsive to the total number of FRUs being equal to the allocated number of FRUs, determining that there are no un-allocated FRUs in the first UTTU,and responsive to the total number of FRUs being greater than the allocated number of FRUs determining that there are un-allocated FRUs in the first UTTU.

6. The method of claim 5, wherein determining the first number of FRUs further comprises: responsive to determining that there are no un-allocated FRUs in the first UTTU, selecting (415) the respective initial number of FRUs for the first UE as the first number of FRUs.

7. The method of claim 5 or 6, wherein determining the first number of FRUs further comprises: responsive to determining that there are un-allocated FRUs in the first UTTU, selecting (405) a number of the un-allocated FRUs to be allocated to the first UE in addition to the respective initial number of FRUs for the first UE.

8. The method of claim 7, wherein selecting the number of the un-allocated FRUs to be allocated to the first UE comprises: identifying (301) one or more qualifying SRs comprising the first SR; and distributing (302) the un-allocated FRUs amongst one or more UEs that sent the one or more qualifying SRs.

9. The method of claim 8, wherein identifying the one or more qualifying SRs comprises selecting the one or more qualifying SRs from a set of one or more SRs each received from a UE that has each been allocated at least one FRU in the first UTTU, wherein each qualifying SR is selected based on one or more of: a logical channel priority associated with the qualifying SR; a priority index associated with the qualifying SR; a prediction of a logical channel buffer size for a UE that sent the qualifying SR; a relationship between the predicted logical channel buffer size for the UE that sent the qualifying SR and the un-allocated FRUs in the first UTTU; and a measured uplink signal to interference plus noise power ratio, SINR, for the UE that sent the qualifying SR.

10. The method of claim 8 or 9, wherein the un-allocated FRUs are distributed amongst the one or more UEs that sent the one or more qualifying SRs based on one or more characteristics of at least one qualifying SR.

11. The method of claim 10, wherein the one or more characteristics comprise one or more of: a logical channel priority associated with the qualifying SR; a priority index associated with the qualifying SR; a prediction of a logical channel buffer size for a UE that sent the qualifying SR; a relationship between the predicted logical channel buffer size for the UE that sent the qualifying SR and the number of un-allocated FRUs in the first UTTU; and a measured uplink signal to interference plus noise power ratio, SINR, for the UE that sent the qualifying SR.

12. The method of any preceding claim, wherein determining the first number of FRUs to allocate to the first UE is performed responsive to identifying that the first SR is a qualifying SR.

13. The method of any preceding claim, wherein determining the first number of FRUs to allocate to the first UE is performed responsive to determining that a load associated with the network node satisfies a criterion.

14. The method of claim 13, wherein the criterion is satisfied when the load associated with the network node is below a threshold value.

15. The method of any preceding claim, wherein the method further comprises: after transmitting the uplink grant, receiving (406, 418), from the first UE, data on at least one of the first number of FRUs allocated to the first UE.

16. The method of any preceding claim, wherein the FRUs are resource blocks.

17. A network node (510A, 510B, 600, 700) for grant-based scheduling of frequency resource units, FRUs to one or more user equipments, the network node (510A, 510B, 600, 700) adapted to:receive (201) a first scheduling request, SR, from a first User Equipment, UE; responsive to receiving the first SR, select (202) to allocate FRUs of a first uplink time-based transmission unit, UTTU, to the first UE; determine (203) a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE; and transmit (204), to the first UE, an uplink grant for transmission using the first number of FRUs.

18. The network node (510A, 510B, 600, 700) of claim 17, further adapted to perform the method of any of claims 2-16.

19. A network node for grant-based scheduling of frequency resource units, FRUs to one or more user equipments, the network node comprising a processor and a memory, the memory containing instructions executable by the processor whereby the network node is operative to: receive (201) a first scheduling request, SR, from a first User Equipment, UE; responsive to receiving the first SR, select (202) to allocate FRUs of a first uplink time-based transmission unit, UTTU, to the first UE; determine (203) a first number of FRUs to allocate to the first UE based on whether there would be un-allocated FRUs in the first UTTU after an initial allocation of FRUs in the first UTTU to the one or more UEs comprising the first UE; and transmit (204), to the first UE, an uplink grant for transmission using the first number of FRUs.

20. The network node of claim 19, further operative to perform the method of any of claims 2-16.

21. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1-16.

22. A computer-readable medium comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1-16.

23. A carrier containing the computer program of claim 21, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer-readable medium.

Images