WO2016130060A1

WO2016130060A1 - Systems and methods for managing a wireless communication device's (wcd's) transmit buffer

Info

Publication number: WO2016130060A1
Application number: PCT/SE2015/050168
Authority: WO
Inventors: Anders Ohlsson; Christer Gustafsson
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-02-12
Filing date: 2015-02-12
Publication date: 2016-08-18

Abstract

Methods and systems for managing a transmit buffer of a wireless communication device, WCD, (110). In one aspect, a scheduler node apparatus (105) determines that a catch-up scheduling grant should be sent based on the WCD's buffer status information, channel conditions, and a packet delay budget. In one aspect, the scheduler node transmits to the WCD the scheduling grant. In another aspect, the scheduler node receives the encoded block of data transmitted by the WCD in response to the scheduling grant message. In another aspect, in response to receiving the encoded block of data, the scheduler node sends a hybrid automatic repeat acknowledgement to the WCD regardless of whether the received encoded data block has been successfully decoded.

Description

SYSTEMS AND METHODS FOR MANAGING A WIRELESS COMMUNICATION

DEVICE'S (WCD'S) TRANSMIT BUFFER

TECHNICAL FIELD

[001] Aspects of this disclosure relate the management of a wireless communication device's transmit buffer.

BACKGROUND

[002] Wireless communication devices (e.g., smartphones, tablets, phablets, personal computers, etc.) can be used to transmit time-sensitive data to a receiving communication device. For example, applications like FaceTime® and Skype® enable a user of a wireless

communication device (WCD) to have video calls. That is, WCDs may include a camera for generating video data and a transmitter for transmitting to a radio access network (RAN) node (e.g., a nodeB, an evolved nodeB (eNB), a radio network controller (RNC), etc.) data packets containing the generated video data. The RAN node then retransmits the packets towards the receiving device. Such video data is time-sensitive because if a block of generated video data is not received within a certain amount of time from when the video data was generated, the video data will be of little to no use to the recipient. This amount of time is known as an end-to-end delay budget. In some applications, the end-to-end delay budget is about 200 milliseconds (ms), other applications may have an end-to-end delay budget of 100 ms.

[003] A WCD has a transmit buffer for temporarily storing the generated video data before it is transmitted. Over a certain period of time, if the average rate at which the video data is being generated exceeds the average transmission rate, then the amount of video data in the transmit buffer waiting for transmission will grow (the amount of data in the transmit buffer waiting for transmission is referred to as the "transmit buffer size"). Additionally, not only will the transmit buffer size grow, but video data in the buffer may become stale. For example, if a particular block of data (e.g., video frame) is generated for an application where the end-to-end delay budget is 100 ms and the video frame has been sitting in the buffer for almostl OO ms, then, because of other inherent delays in the network, the video frame will likely be stale because it will likely not be able to be received at the end receiving device within the 100 ms end-to-end delay budget. Accordingly, an increase in the size of the transmit buffer may lead to a low Quality of Experience (QoE) to the end user. SUMMARY

[004] When the WCD's transmission rate falls behind the data generation rate it would be advantageous to provide additional network resources to the WCD so that its transmission rate can be increased and, consequently, the transmit buffer size reduced. The problem with this solution is that, if the network is heavily loaded, then the network may not have any available additional network resources to grant to the WCD or the radio conditions do not allow more resources to be allocated to the WCD in an efficient way (the WCD is power limited, i.e. not enough energy can be generated per resource from the WCD).

[005] One solution for decreasing the transmit buffer size without utilizing an excessive amount of network resources (e.g., time slots, resource blocks, etc.) is for the network to: 1) determine an amount of data in the transmit buffer that can be discarded (e.g., determine the number of video frames in the transmit buffer that are "stale") and 2) transmit to the WCD a scheduling grant that implicitly determines a transport block size (TBS) that is equal to or less than the determined amount of data in the transmit buffer that can be discarded.

Advantageously, because the data in the buffer can be discarded, the scheduling grant generated by the network can specify a high bit rate modulation and coding scheme (MCS) (to fit the amount of data on the resources possible to allocate).

[006] Thus, the scheduling grant may allow the WCD to transmit a relatively large block of data with minimal encoding. For example, the network (e.g., eNB or RNC) can transmit to the WCD a scheduling grant specifying a large transport block size (TBS) and also specifying encoding parameters that will result in the WCD minimally encoding the transmitted data. In such a situation, it may be likely that the network (e.g., eNB or RNC) is not able to decode the transmission due to the minimal error encoding that was used. Nevertheless, even if the transmission cannot be decoded, the network responds to the transmission by sending an acknowledgement (ACK) (e.g., sending a hybrid repeat request (HARQ) ACK) so that the WCD will not retransmit the data and remove it from the transmit buffer. In this way, a large amount of data can be transmitted using few network resources than would have been used if the encoding parameters corresponded to a non-minimal encoding scheme.

[007] Accordingly, in one aspect there is provided a method performed by a scheduler node apparatus (a.k.a., "scheduler") (e.g., radio network controller, RNC, or an evolved nodeB, eNB) for managing a transmit buffer of a wireless communication device (WCD). In some embodiments, the method includes the scheduler receiving from the WCD a message comprising buffer status information indicating an amount of time-sensitive data in the transmit buffer of the WCD. The method further includes the scheduler determining that a catch-up scheduling grant should be sent based on at least the buffer status information, channel conditions, and a packet delay budget, and also determining an amount of the time-sensitive data in the transmit buffer of the WCD that can be discarded. The scheduler, in response to determining that a catch-up scheduling grant should be sent, generates a scheduling grant that implicitly determines a transport block size, TBS, that is less than or equal to the determined amount of time-sensitive data in the transmit buffer that can be discarded. The scheduler then transmits to the WCD the scheduling grant, wherein the scheduling grant message comprises parameters indicating a modulation and coding scheme (MCS) in combination with a set of resources to cause the WCD to transmit an encoded block of data encoded in accordance with the determined TBS. After which, the scheduler receives the encoded block of data transmitted by the WCD in response to the scheduling grant message. In response to receiving said encoded block of data, the scheduler sends a hybrid automatic repeat request, HARQ, acknowledgement, ACK, to the WCD regardless of whether the received encoded data block has been successfully decoded.

[008] In some embodiments, the method further includes the scheduler discarding the encoded block of data without attempting to decode the encoded block of data.

[009] In some embodiments, determining that a catch-up scheduling grant should be sent comprises determining if the amount of time-sensitive data in the transmit buffer exceeds a threshold value. In some embodiments, the threshold value is determined based on at least the packet delay budget and at least one of a maximum bitrate and a guaranteed bitrate.

[0010] In some embodiments, generating the scheduling grant comprises selecting a scheduling grant parameter based on at least the determined amount of time-sensitive data in the transmit buffer that can be discarded. In some embodiments, the scheduling grant parameter is the parameter indicating the MCS.

[0011] The above and other aspects and embodiments are described below with reference to the accompanying drawings.

BRIEF DESCRIPTION OF DRAWINGS [0012] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0013] FIG. 1 is a block diagram of a communication network, according to some embodiments.

[0014] FIG. 2 is a flow chart illustrating a process, according to some embodiments.

[0015] FIG. 3 is a block diagram of a scheduler node apparatus, according to some embodiments.

DETAILED DESCRIPTION

[0016] FIG. 1 is a block diagram of a communication network 100, according to some embodiments. As shown in FIG. 1, communication network 100 includes a scheduler node apparatus 105 (a.k.a., "scheduler 105"), which is a component of a core network 150. Scheduler 105 may comprise or consist of a radio access network (RAN) node and be in communication with a WCD 110 such that data may be transmitted between WCD 110 and scheduler 105 via an antenna 115 (e.g., a base station antenna).

[0017] The embodiments disclosed herein are not limited to any specific type of core network 150. However, in embodiments where core network 150 is a Long Term Evolution (LTE) core network, scheduler 105 may comprise or consist of an evolved NodeB (eNB). In embodiments where core network 150 is a WCDMA 3G cellular system, scheduler 105 may comprise or consist of a RNC.

[0018] In some embodiments, WCD 110 may transmit data to network 150 only during specified time intervals using discontinuous reception (DRX). DRX may reduce battery consumption in WCD 110 by limiting the time when WCD 110 needs to monitor reception. Since WCD 110 can only be scheduled by scheduler 105 when WCD 110 monitors the physical downlink control channel (PDCCH), WCD 110 can only be scheduled during very specific periods of time when WCD 110 is awake. Thus, in some embodiments, scheduler 105 may configure the DRX for multiple WCDs 110 so that the multiple WCDs 110 do not have simultaneous wake times in order to spread out the load on network 150.

[0019] For a good QoE, good battery performance may be important, i.e. the battery of

WCD 110 should last until the next charging opportunity. Packet intensive services, such as voice over IP (VoIP), voice over LTE (VoLTE), and video-telephony services, that require a continuous flow of packets may put higher demands on the battery performance of WCD 110. One way to increase the battery performance of WCD 110 is to use DRX, where WCD 110 is allowed to turn off the receiver and hence save battery power.

[0020] In embodiments where core network 150 is an LTE network, packets may be transmitted through core network 150 using the IP protocol. Thus, traditionally circuit switched services such as conversational voice may be provided using voice over IP (VoIP). In some VoIP arrangements, a voice encoder on the transmitter side (i.e., WCD 110) may encode speech into packets, with a typical speech duration of 20 ms (e.g., as specified by the Global System for Mobile Communications IR. 94 - IMS Profile for Conversational Video Systems). Voice over LTE (VoLTE) enables LTE networks to provide voice services, including the voice component in conversational video services.

[0021] Conversational video services may further include video-telephony, i.e., providing a moving picture with the conversational voice service. The video may be encoded using a video compression format (e.g., a video codec such as H.264 or H.265), using a variable bitrate to perform motion compensation. For example, the more movement in the video picture, the higher the bitrate, and the less movement in the video picture, the lower the bitrate.

[0022] Certain applications, such as VoIP, require a certain quality of service (QoS).

QoS defines priorities for certain services during times of high congestion in core network 150. In some embodiments, QoS may be implemented between WCD 110 and scheduler 105 by configuring a bearer that defines how WCD 110 data is treated when it travels through core network 150.

[0023] When WCD 110 attaches to network 150 for the first time, it may be assigned a default bearer that remains as long as WCD 110 is attached. The default bearer may specify a "best effort" service and a unique IP address. In some instances, a dedicated bearer may be used on top of the default bearer in order to provide a dedicated tunnel for one or more specific types of traffic when there is a need to meet a certain QoS (e.g., VoIP, video, etc.). The dedicated bearer may not require a separate IP address since it is may be linked to the default bearer that has an IP address. The dedicated bearer may be of either a Guaranteed Bit Rate (GBR) type or a non-GBR type, whereas the default bearer may only be of a non-GBR type. Dedicated bearers use traffic flow templates (TFT) to provide preferential treatment to specific services.

[0024] In some embodiments, each bearer may have an associated QoS class identifier

(QCI) rating depending on what level of QoS is expected for a given service. The QCI may be made up of, for example, the following characteristics: 1) resource type (GBR or non-GBR); 2) priority (the lower the number the higher the priority); 3) end-to-end or packet delay budget (the lower the number the faster the service); and 4) packet error loss (the lower the value the better the service performance). In embodiments where WCD 110 is connected to a number of public data networks (e.g., IMS, Internet, VPN), WCD 110 may need to configure several radio bearers. Furthermore, in some embodiments, several radio bearers may be grouped as a logical channel group (LCG).

[0025] The scheduler 105 may obtain configuration information relating to the bearer for a specific WCD 1 10, which may include, for example, a GBR value, a maximum bit rate (MBR) value, and a packet delay budget.

[0026] To initiate a service, WCD 110 may submit a scheduling request (e.g., a 1 bit message) towards scheduler 105 in order to begin transmitting data. In response, scheduler 105 may transmit a scheduling grant to WCD 110, which implicitly limits the maximum amount of data WCD 1 10 may transmit in its next transmission. In response to receiving a scheduling grant from scheduler 105, WCD 110 may transmit uplink data in accordance with the parameters set by the grant. For example, the scheduling grant includes data implicitly determining a maximum transport block size (TBS) (e.g., the grant includes data specifying, among other things, a modulation and coding scheme (MCS) to be used by WCD 1 10 to transmit data in the uplink and a number of physical resource blocks (PRBs)). As described herein, the scheduling grant may be generated by scheduler 105 such that the scheduling grant implicitly determines a particular TBS that was selected by scheduler 105 based on the current network 150 conditions and the amount of data in the buffer of WCD 1 10.

[0027] In some embodiments, each transmission from WCD 1 10 may be associated with a Hybrid Automatic Repeat Request (HARQ) process. HARQ involves an encoded forward link for error correction and detection and a feedback link for indication of possible retransmission. Each HARQ process may hold the state, parameters and the payload data. At the transmitter, such as WCD 1 10, parity bits may be added to the data block to detect and correct errors. In case the receiver, such as scheduler 105, is not able to correct these errors, the data block must be transmitted again by WCD 1 10. Thus, for each data block received at scheduler 105, scheduler 105 may either send an ACK (data block is received or decoded successfully) or a NACK (data block is not decodable) response to WCD 1 10. The WCD 110 may respond to a NACK message by re-transmitting the information. In contrast, if a new transmission, indicated by the New Data Indicator (NDI) bit, is received at the HARQ process, and WCD 110 receives an ACK message, WCD 110 may flush the old pay load data.

[0028] Uplink HARQ is a synchronous stop and wait protocol, and (re)transmissions are restricted to occur at known time instants, in between which WCD 1 10 stops and waits for ACK/NACK feedback from scheduler 105. Thus, a subsequent transmission of new data in the uplink from WCD 1 10 can take place only after WCD 1 10 receives an ACK NACK from scheduler 105. In some embodiments, the HARQ scheme can be improved by using multiple HARQ processes to be able to fully utilize the air interface. When WCD 110 has reached the maximum number of retransmissions for a transport block without getting an ACK from scheduler 105, it may stop transmitting and let higher layer ARQ take over (e.g., RLC or TCP), if any exists.

[0029] In instances where WCD 110 has more data to transmit remaining in its buffer after transmitting uplink data in accordance with the grant, WCD 110 may also transmit a buffer status report (BSR) to scheduler 105. The BSR may be a Media Access Control (MAC) Control Element (CE), and may be sent from WCD 110 to the serving scheduler 105 to provide information about the remaining data to transmit in the uplink buffer of WCD 1 10. The BSR may contain two fields, the logical channel group ID (LCG ID) and the transmit buffer size. The LCG ID field in the BSR identifies the group of logical channel(s) of WCD 1 10 for which buffer status is being reported. The length of the LCG ID field may be 2 bits. The transmit buffer size field in the BSR may identify the total amount of data to transmit across all logical channels of a logical channel group after all MAC PDUs for the TTI have been built. The transmit buffer size may be indicated in number of bytes and may include all data that is available for transmission in the RLC layer and in the PDCP layer. [0030] For many services, particularly those that require a minimum QoS and/or QoE, it may be difficult for scheduler 105 to perform a good granting strategy while simultaneously keeping core network 150 resource usage at an acceptable level, not introducing delays, and catering to a good battery performance of WCD 110.

[0031] For example, the varying bitrate of certain video services may affect the size of the video frame as well as the number of packets required to transfer the video frame. Each packet is limited by the maximum transmission unit (MTU) size, which may be 1280 bytes, and hence decides the number of packets for a frame. In order to provide adequate QoS and not exceed the packet or end-to-end delay budget, scheduler 105 may be required to "over grant," which leads to network resource waist.

[0032] Additionally, in the case of DRX to improve battery performance, short onDuration and inactivity times must be used in order to use services such as voice and conversational video where a lot of packets are transferred. These short time intervals may make it nearly impossible for scheduler 105 to make use of the information in a BSR until the next onDuration, i.e. a DRX cycle later.

[0033] If the scheduling of the video stream or other service with a specified QoS falls behind, the only possible way for WCD 110 to catch up {i.e., empty its buffer) is to use extensive amount of resources, which requires an unloaded scheduler 105, or hope for a rapid improvement of the network conditions. The PDCP Discard Timer may also be difficult to use since its granularity also requires radio resource control (RRC) signaling to be reconfigured. The timer may need to be set to a higher than desired value in order to not to affect the service quality in normal conditions, which leads to a risk of data in WCD 110 buffer growing when the bitrate increases.

[0034] In some embodiments, the growing video data buffer in WCD 110 may eventually reach a level where a constant high delay is the result. The delay will give a low QoE to the end user. In such a scenario, there exists a need to reduce the buffer size of WCD 110 by dropping some old data in a timely manner.

[0035] FIG. 2 is a flow chart illustrating a process 200, according to some embodiments, for managing a transmit buffer of WCD 110. In exemplary embodiments, process 200 is performed by scheduler 105. In step 202, scheduler 105 receives a message from WCD 110 comprising buffer status information indicating an amount of time-sensitive data in a transmit buffer of WCD 110. In some embodiments, the message may comprise or consist of a BSR, described above.

[0036] In step 204, scheduler 105 determines that a "catch-up" scheduling grant should be sent based on at least the buffer status information, channel conditions, and a packet delay budget. In normal operation where a WCD 100 is using DRX, scheduler 105 may aim to empty WCD 110's transmit buffer at almost each onDuration time interval in order to maintain a steady state when it comes to delay. A "catch-up" scheduling grant may be needed, for example, in scenarios where the scheduling of WCD 110 falls behind, i.e., the buffer size of WCD 110 is growing and scheduler 105 may not be able to maintain the packet delay budget (PDB). The fall behind scenario could result in situations where there is a rapid increase in video bitrate due to motion compensation, a deteriorating radio environment, or a combination of both. For example, a fall behind scenario may be indicated when the MBR rate needs to be used to either empty the buffer of WCD 110 within the packet delay budget or, even worse, when the MBR rate needs to be used to just schedule the data transmission within the PDB without being able to empty the buffer of WCD 110.

[0037] In some embodiments, scheduler 105 may determine that a catch-up scheduling grant should be sent where the amount of time-sensitive data in the buffer of WCD 110, as indicated in the BSR, exceeds a threshold value. The threshold value may be pre-defined or may be calculated based on the packet delay budget and at least one of a maximum bitrate and a guaranteed bitrate.

[0038] For example, if WCD 110 is operating in DRX mode, the threshold value may reflect a situation where WCD 110 cannot empty its buffer and will not be able to empty its buffer in the next onDuration cycle (or a specified number of onDuration cycles) if it transmits using the MBR. In the case of a conversational video service, scheduler 105 may calculate an upper limit on the amount of data WCD 110 may transmit in the uplink in the next onDuration cycle based on either the GBR or the MBR. For example, using the GBR, an upper limit

("GBRonduration") ^on the amount of data WCD 110 may transmit in the next DRX cycle may be calculated by multiplying the DRX cycle time (seconds) by (GBR - the video bitrate).

Likewise, using the MBR, an upper limit ("MBR_on_dur_ati_on") on the amount of data WCD 1 10 may transmit in the next DRX cycle may be calculated by multiplying the DRX cycle time (seconds) by (MBR - the video bitrate). Thus, in some embodiments, scheduler 105 may determine that a catch-up grant is needed where amount of time-sensitive data in the transmit buffer exceeds the GBRonduration value or the MBRonduration value.

[0039] In another example, the threshold value may reflect a situation where WCD 110 cannot meet the packet delay budget if it transmits according to the MBR. This threshold value ("ThresholdpdbMax") may be calculated by multiplying the packet delay budget (seconds) by the MBR (kilobits (kb)/s).

[0040] In step 206, scheduler 105 determines an amount of time-sensitive data in the transmit buffer that can be discarded. In general, the amount of data that can be discarded may be determined by calculating the delta between the amount of time-sensitive data in the transmit buffer of WCD 110 and the desired buffer size in WCD 110.

[0041] In some embodiments, the desired buffer size may be a value (MBR_Pdb) reflecting the upper limit of the amount of data that may remain in a buffer if WCD 110 is transmitting at the MBR and is able meet the packet delay budget. In the case of a video service, the MBR_Pdb value may be calculated by multiplying the packet delay budget by (MBR - video bitrate).

[0042] In some embodiments, the desired buffer size may be a value (GBR_Pdb) reflecting the upper limit of the amount of data that may remain in the buffer if WCD 110 is transmitting at the GBR and is able to meet the packet delay budget. In the case of the video service, the

GBR_pdb value may be calculated by multiplying the packet delay budget by (GBR - video bitrate).

[0043] Thus, in some embodiments, the scheduler node may determine the amount of time-sensitive data in the transmit buffer that can be discarded by calculating the difference between the amount of time-sensitive data in the transmit buffer of WCD 110 and the MBR_Pdb or the GBR_pdb. In some embodiments, the scheduler node may first determine to reduce the amount of time-sensitive data to the MBR_Pdb value. However, if the transmit buffer size of WCD 1 10 continues to grow, scheduler 105 may determine that a second catch -up grant should be sent to reduce the transmit buffer size to the GBR_Pd value. [0044] In some instances, the desired buffer size in WCD 110 may need to be compensated based on the type of service being used. For example, in the case of a WCD 1 10 operating in DRX mode and providing a video transmission service, the determined amount of time sensitive-data to discard may be calculated by multiplying the video rate by the DRX cycle time, adding the amount of time-sensitive data in the transmit buffer of WCD 1 10, and subtracting either the MBR_Pd or the GBR_ptj_b values.

[0045] In step 208, scheduler 105, in response to determining that a catch-up scheduling grant should be sent, generates a scheduling grant that implicitly determines a transport block size (TBS) that is less than or equal to the determined amount of time-sensitive data in the transmit buffer that can be discarded. In some embodiments, scheduler 105 selects a scheduling grant parameter based on at least the determined amount of time-sensitive data in the transmit buffer that can be discarded. In some embodiments, the scheduling grant parameter is the parameter indicating the MCS.

[0046] In step 210, scheduler 105 transmits the scheduling grant to WCD 110, wherein the scheduling grant message comprises parameters indicating a modulation and coding scheme (MCS) in combination with a set of resources to cause the WCD to transmit an encoded block of data encoded in accordance with the determined TBS.

[0047] In step 212, scheduler 105 receives the encoded block of data transmitted by

WCD 110 in response to the scheduling grant message.

[0048] In step 214, in response to receiving the encoded block of data, scheduler 105 sends a hybrid automatic repeat request (HARQ) acknowledgement (ACK) to the WCD regardless of whether the received encoded data block has been successfully decoded. In some embodiments, scheduler 105 discards the received encoded block of data without attempting to decode the encoded block of data. Thus, scheduler 105 may "fake" a successful transmission of data by sending an ACK to WCD 1 10 regardless if the data is discarded, thereby allowing WCD 1 10 to empty at least a portion of its buffer.

[0049] FIG. 3 is a block diagram of scheduler node apparatus 105, according to some embodiments. As shown in FIG. 3, scheduler node apparatus 105 may include or consist of: a computer system (CS) 302, which may include one or more processors 355 (e.g., a

microprocessor) and/or one or more circuits, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), a logic circuit, and the like; a network interface 305 for connecting apparatus 105 to a network 150; and a data storage system 308, which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)).

[0050] In embodiments where apparatus 105 includes a processor 355, a computer program product (CPP) 333 may be provided. CPP 333 includes or is a computer readable medium (CRM) 342 storing a computer program (CP) 343 comprising computer readable instructions (CRI) 344 for performing steps described herein (e.g., one or more of the steps shown in FIG. 2). CP 343 may include an operating system (OS) and/or application programs. CRM 342 may include a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), solid state devices (e.g., random access memory (RAM), flash memory), and the like.

[0051] In some embodiments, the CRI 344 of computer program 343 is configured such that when executed by computer system 302, the CRI causes the apparatus 105 to perform steps described above (e.g., steps described above and below with reference to the flow charts shown in the drawings). In other embodiments, scheduler node apparatus 105 may be configured to perform steps described herein without the need for a computer program. That is, for example, computer system 302 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[0052] While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

[0053] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

1. A method performed by a scheduler node apparatus (105) for managing a transmit buffer of a wireless communication device, WCD, (1 10) the method comprising:

receiving from the WCD a message comprising buffer status information indicating an amount of time-sensitive data in the transmit buffer of the WCD;

determining that a catch-up scheduling grant should be sent based on at least the buffer status information, channel conditions, and a packet delay budget;

determining an amount of the time-sensitive data in the transmit buffer of the WCD that can be discarded;

in response to determining that a catch-up scheduling grant should be sent, generating a scheduling grant that implicitly determines a transport block size, TBS, that is less than or equal to the determined amount of time-sensitive data in the transmit buffer that can be discarded; transmitting to the WCD the scheduling grant, wherein the scheduling grant message comprises parameters indicating a modulation and coding scheme (MCS) in combination with a set of resources to cause the WCD to transmit an encoded block of data encoded in accordance with the determined TBS;

receiving the encoded block of data transmitted by the WCD in response to the scheduling grant message; and

in response to receiving said encoded block of data, sending a hybrid automatic repeat request, HARQ, acknowledgement, ACK, to the WCD regardless of whether the received encoded data block has been successfully decoded.

2. The method of claim 1 , further comprising discarding the encoded block of data without attempting to decode the encoded block of data.

3. The method of claim 1 or 2, wherein determining that a catch -up scheduling grant should be sent comprises determining if the amount of time-sensitive data in the transmit buffer exceeds a threshold value.

4. The method of claim 3, wherein the threshold value is determined based on at least the packet delay budget and at least one of a maximum bitrate and a guaranteed bitrate.

5. The method of any one of claims 1-4, wherein generating the scheduling grant comprises selecting a scheduling grant parameter based on at least the determined amount of time-sensitive data in the transmit buffer that can be discarded.

6. The method of claim 5, wherein the scheduling grant parameter is the parameter indicating the MCS.

7. The method of any one of claims 1 -6, wherein the scheduler node apparatus is a radio network controller, RNC, or an evolved nodeB, eNB.

8. A scheduling node apparatus (105) for managing a transmit buffer of a wireless communication device, WCD, (110), the scheduling node apparatus being configured to:

determine that a catch-up scheduling grant should be sent to the WCD based on at least buffer status information indicating an amount of time-sensitive data in the transmit buffer of the WCD, channel conditions, and a packet delay budget;

determine an amount of the time-sensitive data in the transmit buffer of the WCD that can be discarded;

in response to determining that a catch-up scheduling grant should be sent, generate a scheduling grant that implicitly determines a transport block size, TBS, that is less than or equal to the determined amount of time-sensitive data in the transmit buffer that can be discarded; transmit to the WCD the scheduling grant, wherein the scheduling grant message comprises parameters indicating a modulation and coding scheme (MCS) in combination with a set of resources to cause the WCD to transmit an encoded block of data encoded in accordance with the determined TBS; and

in response to receiving the encoded block of data transmitted by the WCD in response to the scheduling grant message, send a hybrid automatic repeat request, HARQ,

acknowledgement, ACK, to the WCD regardless of whether the received encoded data block has been successfully decoded.

9. The scheduling node apparatus of claim 8, further configured to discard the encoded block of data without attempting to decode the encoded block of data.

10. The scheduling node apparatus of claim 8 or 9, further configured to determine if the amount of time-sensitive data in the transmit buffer exceeds a threshold value.

11. The scheduling node apparatus of claim 10, further configured to determine said threshold value based on at least the packet delay budget and at least one of a maximum bitrate and a guaranteed bitrate.

12. The scheduling node apparatus of any one of claims 8-11, further configured to select a scheduling grant parameter based on at least the determined amount of time-sensitive data in the transmit buffer that can be discarded.

13. The scheduling node apparatus of claim 12, wherein the scheduling grant parameter is the parameter indicating the MCS.

14. The scheduling node apparatus of any one of claims 8-13, wherein the scheduler node is a radio network controller or an evolved nodeB.