Patent Description:
<CIT> discloses a method for transmitting uplink data in a wireless communication system including receiving physical uplink control channel resources for transmission of a buffer status report message, and transmitting the buffer status report message through the allocated resources.

<CIT> discloses the transmission of one or more uplink control information bits in a physical uplink control channel. The method includes determining resources allocated for providing the uplink control information it orbits based on a type of service associated with the user equipment, and sending a physical uplink control channel message with the one or more uplink control information bits using the allocated resources.

The scope of the present invention is defined by the scope of the appended claims. Any embodiments that do not fall under the scope of the claims are examples which are useful for understanding the invention, but do not form a part of the invention.

Various embodiments will be described in detail with reference to the accompanying drawings. References made to particular examples and embodiments are for illustrative purposes, and are not intended to limit the scope of the claims.

Various embodiments include systems and methods for communicating information in a physical uplink control channel (PUCCH) message that is in addition to information typically included in the PUCCH message. Various embodiments may improve application layer performance by including such information in the PUCCH message without consuming, for example, uplink data bandwidth, such as physical uplink shared channel (PUSCH) slots.

The term "wireless device" is used herein to refer to any one or all of wireless router devices, wireless appliances, cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, ultrabooks, palmtop computers, wireless electronic mail receivers, multimedia Internet-enabled cellular telephones, medical devices and equipment, biometric sensors/devices, wearable devices including smart watches, smart clothing, smart glasses, smart wrist bands, smart jewelry (e.g., smart rings, smart bracelets, etc.), entertainment devices (e.g., wireless gaming controllers, music and video players, satellite radios, etc.), wireless-network enabled Internet of Things (IoT) devices including smart meters/sensors, industrial manufacturing equipment, large and small machinery and appliances for home or enterprise use, wireless communication elements within autonomous and semiautonomous vehicles, wireless devices affixed to or incorporated into various mobile platforms, global positioning system devices, and similar electronic devices that include a memory, wireless communication components and a programmable processor.

The term "system in a package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computational units, cores and/or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, the SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unifying substrate. A SIP may also include multiple independent SOCs coupled together via high speed communication circuitry and packaged in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high speed communications and the sharing of memory and resources.

The term "short data field" is used herein to refer to a field added to a control channel message, such as a PUCCH message, to convey a message or information in addition to information typically included or transmitted in PUCCH messages. Information that is typically transmitted in a PUCCH message includes uplink control information, which may include Hybrid Automatic Repeat Request (HARQ) feedback (e.g., HARQ Ack bits), scheduling requests (SR), and downlink channel state information (CSI). Additional information conveyed in a short data field may include, for example, a TCP acknowledgment information that is included in the short data field is referred to herein as an "uplink message. " In some embodiments, the short data field may also include control information not typically included in the PUCCH, such as a buffer status report (BSR). (TCP Ack), an ultra-reliable low latency communication (URLLC) uplink transmission, or application information such as a virtual reality (VR) sensor pose.

Conventional time division duplex (TDD) cellular communication systems utilize uplink data slots in the PUSCH to convey data, periodic reports and feedback from a wireless device to a communication network. An application or service requiring frequent reports or feedback may cause a reduction in available bandwidth to carry data. In particular, services that require frequent uplink feedback, such as a downlink transfer control protocol (TCP) connection, require frequent uplink data slot allocations to provide feedback such as a TCP acknowledgment (TCP Ack). This requirement results in a lowering of the downlink duty cycle and a reduction in available data carriage bandwidth for the wireless device. TCP requires a receiving device, such as the wireless device, to acknowledge the successful receipt of data packets. To avoid the inefficiency of waiting for acknowledgment of every packet before sending the next packet, a TCP sending device uses a TCP window to determine a number of packets likely to be sent without loss. The TCP sending device reduces its transmission rate when it does not receive a TCP Ack within an expected timeframe. Thus, feedback latency, such as TCP Ack latency, may dramatically affect data throughput.

Various embodiments enable a wireless device to communicate an uplink message including information that would ordinarily be transmitted in a data channel in a PUCCH message. In accordance with the invention, the wireless device may configure a PUCCH message with a new short data field that includes the uplink message. The wireless device may send the PUCCH message including the short data field to convey the uplink message to a communication network.

The wireless device may use the short data field to convey an acknowledgment of received data that does not utilize data uplink bandwidth, (e.g., uplink slots in a data channel such as a PUSCH). In some embodiments, a wireless device may receive data from a second wireless device in a downlink channel, may generate acknowledgment message responsive to the received data, and may configure a physical uplink control channel (PUCCH) message to include the acknowledgment message. The wireless device may send the PUCCH message including the short data field that includes the acknowledgement message to acknowledge the received data. The acknowledgment message may include, for example, a TCP acknowledgment message.

The wireless device may concatenate or combine the acknowledgment message and other information in the PUCCH message. In some embodiments, the wireless device may perform a symmetric header compression on the acknowledgement message included in the PUCCH message without compressing other data fields, such as HARQ Ack bits, SR bits, and CSI bits.

The wireless device may receive an instruction from a network element, such as a base station, to enable the wireless device to configure the PUCCH message to include the acknowledgment message. For example, the wireless device may provide an indication to the base station that the wireless device is configured to generate and provide acknowledgment messages in an uplink control channel message. In some embodiments, the base station may send a message or instructions to the wireless device to enable the wireless device to configure the PUCCH message to include the acknowledgment message.

The wireless device may receive instructions from an application executing on the wireless device to enable the wireless device to configure the PUCCH message to include the acknowledgment message. For example, an application executing on the wireless device may require relatively frequent uplink transmissions. One example of such an application is a gaming application, that may require small, frequent uplink transmissions of user action data. Further, such an application may suffer from any substantial decrease in data carriage to or from the wireless device. For example, the gaming application may require a large amount of data to be provided via a downlink data channel, such as video data. In some embodiments, the application executing on the wireless device may send a message or instructions enabling the wireless device to configure the PUCCH message to include the acknowledgment message.

In accordance with the claimed invention, a PUCCH message is configured to include a buffer status report in a short data field, to be sent to a base station. It is determined whether a PUCCH occasion will occur before a scheduling request occasion, and configuring the PUCCH message to include the buffer status report in the short data field in response to determining that that the PUCCH occasion will occur before the scheduling request occasion. Some embodiments may further include sending a scheduling request message to the base station in response to determining that the PUCCH occasion will not occur before the scheduling request occasion. Some embodiments may further include receiving an uplink grant from the base station based on the buffer status report conveyed in the PUCCH message, which may include sending uplink data to the base station during the granted uplink.

<FIG> is a system block diagram illustrating an example communication system <NUM> suitable for implementing any of the various embodiments. The communications system <NUM> may be a <NUM> New Radio (NR) network, or any other suitable network such as a Long Term Evolution (LTE) network.

The communications system <NUM> may include a heterogeneous network architecture that includes a core network <NUM> and a variety of mobile devices (illustrated as wireless device 120a-120e in <FIG>). The communications system <NUM> may also include a number of base stations (illustrated as the BS 110a, the BS 110b, the BS 110c, and the BS 110d) and other network entities. A base station is an entity that communicates with wireless devices (mobile devices), and also may be referred to as an NodeB, a Node B, an LTE evolved nodeB (eNB), an access point (AP), a radio head, a transmit receive point (TRP), a New Radio base station (NR BS), a <NUM> NodeB (NB), a Next Generation NodeB (gNB), or the like. Each base station may provide communication coverage for a particular geographic area. In 3GPP, the term "cell" can refer to a coverage area of a base station, a base station subsystem serving this coverage area, or a combination thereof, depending on the context in which the term is used.

A base station 110a-110d may provide communication coverage for a macro cell, a pico cell, a femto cell, another type of cell, or a combination thereof. A macro cell may cover a relatively large geographic area (for example, several kilometers in radius) and may allow unrestricted access by mobile devices with service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by mobile devices with service subscription. A femto cell may cover a relatively small geographic area (for example, a home) and may allow restricted access by mobile devices having association with the femto cell (for example, mobile devices in a closed subscriber group (CSG)). A base station for a macro cell may be referred to as a macro BS. A base station for a pico cell may be referred to as a pico BS. A base station for a femto cell may be referred to as a femto BS or a home BS. In the example illustrated in <FIG>, a base station 110a may be a macro BS for a macro cell 102a, a base station 110b may be a pico BS for a pico cell 102b, and a base station 110c may be a femto BS for a femto cell 102c. A base station 110a-110d may support one or multiple (for example, three) cells.

In some examples, a cell may not be stationary, and the geographic area of the cell may move according to the location of a mobile base station. In some examples, the base stations 110a-110d may be interconnected to one another as well as to one or more other base stations or network nodes (not illustrated) in the communications system <NUM> through various types of backhaul interfaces, such as a direct physical connection, a virtual network, or a combination thereof using any suitable transport network
The base station 110a-110d may communicate with the core network <NUM> over a wired or wireless communication link <NUM>. The wireless device 120a-120e may communicate with the base station 110a-110d over a wireless communication link <NUM>.

The communications system <NUM> also may include relay stations (e.g., relay BS 110d). A relay station is an entity that can receive a transmission of data from an upstream station (for example, a base station or a mobile device) and transmit the data to a downstream station (for example, a wireless device or a base station). A relay station also may be a mobile device that can relay transmissions for other wireless devices. In the example illustrated in <FIG>, a relay station 110d may communicate with macro the base station 110a and the wireless device 120d in order to facilitate communication between the base station 110a and the wireless device 120d. A relay station also may be referred to as a relay base station, a relay base station, a relay, etc..

The wireless devices 120a, 120b, 120c may be dispersed throughout communications system <NUM>, and each wireless device may be stationary or mobile. A wireless device also may be referred to as an access terminal, a terminal, a mobile station, a subscriber unit, a station, etc..

A macro base station 110a may communicate with the communication network <NUM> over a wired or wireless communication link <NUM>. The wireless devices 120a, 120b, 120c may communicate with a base station 110a-110d over a wireless communication link <NUM>.

The wireless communication links <NUM>, <NUM> may include a plurality of carrier signals, frequencies, or frequency bands, each of which may include a plurality of logical channels. The wireless communication links <NUM> and <NUM> may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in a wireless communication link include 3GPP LTE, <NUM>, <NUM>, <NUM> (e.g., NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile telephony communication technologies cellular RATs. Further examples of RATs that may be used in one or more of the various wireless communication links <NUM>, <NUM> within the communication system <NUM> include medium range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, and relatively short range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

For example, the spacing of the subcarriers may be <NUM> and the minimum resource allocation (called a "resource block") may be <NUM> subcarriers (or <NUM>). Consequently, the nominal Fast File Transfer (FFT) size may be equal to <NUM>, <NUM>, <NUM>, <NUM> or <NUM> for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM> megahertz (MHz), respectively. For example, a subband may cover <NUM> (i.e., <NUM> resource blocks), and there may be <NUM>, <NUM>, <NUM>, <NUM> or <NUM> subbands for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM>, respectively.

While descriptions of some embodiments may use terminology and examples associated with LTE technologies, various embodiments may be applicable to other wireless communications systems, such as a new radio (NR) or <NUM> network. NR may utilize OFDM with a cyclic prefix (CP) on the uplink (UL) and downlink (DL) and include support for half-duplex operation using TDD. A single component carrier bandwidth of <NUM> may be supported. NR resource blocks may span <NUM> subcarriers with a sub-carrier bandwidth of <NUM> over a <NUM> millisecond (ms) duration. Each radio frame may consist of <NUM> subframes with a length of <NUM>. Consequently, each subframe may have a length of <NUM>. Each subframe may indicate a link direction (i.e., DL or UL) for data transmission and the link direction for each subframe may be dynamically switched. Each subframe may include DL/UL data as well as DL/UL control data. Multiple Input Multiple Output (MIMO) transmissions with precoding may also be supported. MIMO configurations in the DL may support up to eight transmit antennas with multi-layer DL transmissions up to eight streams and up to two streams per wireless device. Multi-layer transmissions with up to <NUM> streams per wireless device may be supported. Aggregation of multiple cells may be supported with up to eight serving cells. Alternatively, NR may support a different air interface, other than an OFDM-based air interface.

Some mobile devices may be considered machine-type communication (MTC) or evolved or enhanced machine-type communication (eMTC) mobile devices. MTC and eMTC mobile devices include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., that may communicate with a base station, another device (for example, remote device), or some other entity. A wireless node may provide, for example, connectivity for or to a network (for example, a wide area network such as Internet or a cellular network) via a wired or wireless communication link. Some mobile devices may be considered Internet-of-Things (IoT) devices or may be implemented as NB-IoT (narrowband internet of things) devices. A wireless device 120a-120e may be included inside a housing that houses components of the wireless device, such as processor components, memory components, similar components, or a combination thereof.

In general, any number of communication systems and any number of wireless networks may be deployed in a given geographic area. Each communications system and wireless network may support a particular radio access technology (RAT) and may operate on one or more frequencies. A RAT also may be referred to as a radio technology, an air interface, etc. A frequency also may be referred to as a carrier, a frequency channel, etc. Each frequency may support a single RAT in a given geographic area in order to avoid interference between communications systems of different RATs.

In some embodiments, two or more mobile devices 120a-120e (for example, illustrated as the wireless device 120a and the wireless device 120e) may communicate directly using one or more sidelink channels <NUM> (for example, without using a base station 110a-110d as an intermediary to communicate with one another). For example, the wireless devices 120a-120e may communicate using peer-to-peer (P2P) communications, device-to-device (D2D) communications, a vehicle-to-everything (V2X) protocol (which may include a vehicle-to-vehicle (V2V) protocol, a vehicle-to-infrastructure (V2I) protocol, or similar protocol), a mesh network, or similar networks, or combinations thereof. In this case, the wireless device 120a-120e may perform scheduling operations, resource selection operations, as well as other operations described elsewhere herein as being performed by the base station 110a.

<FIG> is a component block diagram illustrating an example computing and wireless modem system <NUM> suitable for implementing any of the various embodiments. Various embodiments may be implemented on a number of single processor and multiprocessor computer systems, including a system-on-chip (SOC) or system in a package (SIP).

With reference to <FIG> and <FIG>, the illustrated example computing system <NUM> (which may be a SIP in some embodiments) includes a two SOCs <NUM>, <NUM> coupled to a clock <NUM>, a voltage regulator <NUM>, and a wireless transceiver <NUM> configured to send and receive wireless communications via an antenna (not shown) to/from wireless devices, such as a base station 110a. In some embodiments, the first SOC <NUM> operate as central processing unit (CPU) of the wireless device that carries out the instructions of software application programs by performing the arithmetic, logical, control and input/output (I/O) operations specified by the instructions. In some embodiments, the second SOC <NUM> may operate as a specialized processing unit. For example, the second SOC <NUM> may operate as a specialized <NUM> processing unit responsible for managing high volume, high speed (e.g., <NUM> Gbps, etc.), and/or very high frequency short wave length (e.g., <NUM> mmWave spectrum, etc.) communications.

The first SOC <NUM> may include a digital signal processor (DSP) <NUM>, a modem processor <NUM>, a graphics processor <NUM>, an application processor <NUM>, one or more coprocessors <NUM> (e.g., vector co-processor) connected to one or more of the processors, memory <NUM>, custom circuity <NUM>, system components and resources <NUM>, an interconnection/bus module <NUM>, one or more temperature sensors <NUM>, a thermal management unit <NUM>, and a thermal power envelope (TPE) component <NUM>. The second SOC <NUM> may include a <NUM> modem processor <NUM>, a power management unit <NUM>, an interconnection/bus module <NUM>, the plurality of mmWave transceivers <NUM>, memory <NUM>, and various additional processors <NUM>, such as an applications processor, packet processor, etc..

The first and second SOC <NUM>, <NUM> may include various system components, resources and custom circuitry for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources <NUM> of the first SOC <NUM> may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support the processors and software clients running on a wireless device. The system components and resources <NUM> and/or custom circuitry <NUM> may also include circuitry to interface with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, etc..

The first and second SOC <NUM>, <NUM> may communicate via interconnection/bus module <NUM>. The various processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, may be interconnected to one or more memory elements <NUM>, system components and resources <NUM>, and custom circuitry <NUM>, and a thermal management unit <NUM> via an interconnection/bus module <NUM>. Similarly, the processor <NUM> may be interconnected to the power management unit <NUM>, the mmWave transceivers <NUM>, memory <NUM>, and various additional processors <NUM> via the interconnection/bus module <NUM>. The interconnection/bus module <NUM>, <NUM>, <NUM> may include an array of reconfigurable logic gates and/or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects, such as high-performance networks-on chip (NoCs).

The first and/or second SOCs <NUM>, <NUM> may further include an input/output module (not illustrated) for communicating with resources external to the SOC, such as a clock <NUM> and a voltage regulator <NUM>. Resources external to the SOC (e.g., clock <NUM>, voltage regulator <NUM>) may be shared by two or more of the internal SOC processors/cores.

In addition to the example SIP <NUM> discussed above, various embodiments may be implemented in a wide variety of computing systems, which may include a single processor, multiple processors, multicore processors, or any combination thereof.

<FIG> is a component block diagram illustrating a software architecture <NUM> including a radio protocol stack for the user and control planes in wireless communications suitable for implementing any of the various embodiments. With reference to <FIG>, the wireless device <NUM> may implement the software architecture <NUM> to facilitate communication between a wireless device <NUM> (e.g., the wireless device 120a-120e, <NUM>) and the base station <NUM> (e.g., the base station 110a) of a communication system (e.g., <NUM>). In various embodiments, layers in software architecture <NUM> may form logical connections with corresponding layers in software of the base station <NUM>. The software architecture <NUM> may be distributed among one or more processors (e.g., the processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>). While illustrated with respect to one radio protocol stack, in a multi-SIM (subscriber identity module) wireless device, the software architecture <NUM> may include multiple protocol stacks, each of which may be associated with a different SIM (e.g., two protocol stacks associated with two SIMs, respectively, in a dual-SIM wireless communication device). While described below with reference to LTE communication layers, the software architecture <NUM> may support any of variety of standards and protocols for wireless communications, and/or may include additional protocol stacks that support any of variety of standards and protocols wireless communications.

The software architecture <NUM> may include a Non-Access Stratum (NAS) <NUM> and an Access Stratum (AS) <NUM>. The NAS <NUM> may include functions and protocols to support packet filtering, security management, mobility control, session management, and traffic and signaling between a SIM(s) of the wireless device (e.g., SIM(s) <NUM>) and its core network <NUM>. The AS <NUM> may include functions and protocols that support communication between a SIM(s) (e.g., SIM(s) <NUM>) and entities of supported access networks (e.g., a base station). In particular, the AS <NUM> may include at least three layers (Layer <NUM>, Layer <NUM>, and Layer <NUM>), each of which may contain various sub-layers.

In the user and control planes, Layer <NUM> (L1) of the AS <NUM> may be a physical layer (PHY) <NUM>, which may oversee functions that enable transmission and/or reception over the air interface via a wireless transceiver (e.g., <NUM>, <NUM>). Examples of such physical layer <NUM> functions may include cyclic redundancy check (CRC) attachment, coding blocks, scrambling and descrambling, modulation and demodulation, signal measurements, MIMO, etc. The physical layer may include various logical channels, including the Physical Downlink Control Channel (PDCCH) and the Physical Downlink Shared Channel (PDSCH).

In the user and control planes, Layer <NUM> (L2) of the AS <NUM> may be responsible for the link between the wireless device <NUM> and the base station <NUM> over the physical layer <NUM>. In the various embodiments, Layer <NUM> may include a media access control (MAC) sublayer <NUM>, a radio link control (RLC) sublayer <NUM>, and a packet data convergence protocol (PDCP) <NUM> sublayer, each of which form logical connections terminating at the base station <NUM>.

In the control plane, Layer <NUM> (L3) of the AS <NUM> may include a radio resource control (RRC) sublayer <NUM>. While not shown, the software architecture <NUM> may include additional Layer <NUM> sublayers, as well as various upper layers above Layer <NUM>. In various embodiments, the RRC sublayer <NUM> may provide functions INCLUDING broadcasting system information, paging, and establishing and releasing an RRC signaling connection between the wireless device <NUM> and the base station <NUM>.

In various embodiments, the PDCP sublayer <NUM> may provide uplink functions including multiplexing between different radio bearers and logical channels, sequence number addition, handover data handling, integrity protection, ciphering, and header compression. In the downlink, the PDCP sublayer <NUM> may provide functions that include in-sequence delivery of data packets, duplicate data packet detection, integrity validation, deciphering, and header decompression.

In the uplink, MAC sublayer <NUM> may provide functions including multiplexing between logical and transport channels, random access procedure, logical channel priority, and HARQ operations. In the downlink, the MAC layer functions may include channel mapping within a cell, de-multiplexing, discontinuous reception (DRX), and HARQ operations.

While the software architecture <NUM> may provide functions to transmit data through physical media, the software architecture <NUM> may further include at least one host layer <NUM> to provide data transfer services to various applications in the wireless device <NUM>. In some embodiments, application-specific functions provided by the at least one host layer <NUM> may provide an interface between the software architecture and the general purpose processor <NUM>.

In other embodiments, the software architecture <NUM> may include one or more higher logical layer (e.g., transport, session, presentation, application, etc.) that provide host layer functions. For example, in some embodiments, the software architecture <NUM> may include a network layer (e.g., Internet Protocol (IP) layer) in which a logical connection terminates at a packet data network (PDN) gateway (PGW). In some embodiments, the software architecture <NUM> may include an application layer in which a logical connection terminates at another device (e.g., end user device, server, etc.). In some embodiments, the software architecture <NUM> may further include in the AS <NUM> a hardware interface <NUM> between the physical layer <NUM> and the communication hardware (e.g., one or more radio frequency (RF) transceivers).

<FIG> is a component block diagram illustrating a system <NUM> configured for generating an acknowledgment of received data performed by a processor of a wireless device in accordance with various embodiments. In some embodiments, system <NUM> may include a wireless device <NUM> and/or one or more remote platforms <NUM>. With reference to <FIG>, system <NUM> may include a wireless device <NUM> (e.g., 120a-120e, <NUM>, <NUM>) and a second wireless device <NUM> (e.g., 120a-120e, <NUM>, <NUM>). The wireless device <NUM> and the second wireless device <NUM> may communicate over a wireless communication network <NUM> (aspects of which are illustrated in <FIG>).

The wireless device <NUM> may include one or more processors <NUM> coupled to electronic storage <NUM> and a wireless transceiver (e.g., <NUM>, <NUM>). The wireless transceiver may be configured to receive messages to be sent in uplink transmissions from the processor(s) <NUM>, and to transmit such messages via an antenna (not shown) to a wireless communication network <NUM> for relay to remote wireless devices <NUM>. Similarly, the wireless transceiver may be configured to receive messages from remote wireless devices in downlink transmissions from the wireless communication network <NUM> and pass the messages (e.g., via a modem (e.g., <NUM>) that demodulates the messages) to the one or more processors <NUM>.

The processor(s) <NUM> may be configured by machine-readable instructions <NUM>. Machine-readable instructions <NUM> may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of a data receiving module <NUM>, acknowledgement message generating module <NUM>, an uplink control channel message configuration module <NUM>, a message sending module <NUM>,a message configuration module <NUM>, a message information concatenation module <NUM>, a header compression performance module <NUM>, an instruction receiving module <NUM>, or other instruction modules.

The data receiving module <NUM> may be configured to receive data from a second wireless device (e.g., <NUM>) in a downlink channel.

The acknowledgment message generating module <NUM> may be configured to generate an acknowledgement message responsive to the received data.

The uplink control channel message configuration module <NUM> may be configured to configure a physical uplink control channel message to include a short data field that includes an uplink message. In some embodiments, the uplink message may include an acknowledgement message (such as a TCP Ack).

The message sending module <NUM> may be configured to send the PUCCH message including the short data field to acknowledge the received data.

The message configuration module <NUM> may be configured to configure the PUCCH message with the short data field to include the uplink message.

The message information concatenation module <NUM> may be configured to concatenate the acknowledgment message and other information in the PUCCH message.

The header compression performance module <NUM> may be configured to perform a symmetric header compression on the acknowledgment message included in the PUCCH message without compressing other data fields, such as HARQ Ack bits, SR bits, and CSI bits.

The instruction receiving module <NUM> may be configured to receive an instruction from a network element to enable the wireless device to configure the PUCCH message to include the acknowledgment message. The instruction receiving module <NUM> also may be configured to receive an instruction from an application executing on the wireless device to enable the wireless device to configure the PUCCH message to include the acknowledgment message. In some embodiments, the acknowledgment message may be a transfer control protocol acknowledgment (TCP Ack) message.

In some embodiments, the wireless device <NUM>, second wireless device <NUM>, and/or external resources <NUM> may be operatively linked via one or more electronic communication links. For example, such electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes embodiments in which the wireless device <NUM>, second wireless device <NUM>, and/or external resources <NUM> may be operatively linked via some other communication media.

A second wireless device <NUM> may include one or more processors configured to execute computer program modules. The computer program modules may be configured to enable an expert or user associated with the given second wireless device <NUM> to interface with system <NUM> or provide other functionality attributed herein to the second wireless device <NUM>. In some embodiments, the second wireless device <NUM> may include one or more wireless devices or other computing platforms.

The wireless device <NUM> may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of the wireless device <NUM> is not intended to be limiting, and the wireless device <NUM> may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to the wireless device <NUM>.

The electronic storage <NUM> may include non-transitory storage media that electronically stores information. The electronic storage media of electronic storage <NUM> may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with the wireless device <NUM> and/or removable storage that is removably connectable to the wireless device <NUM> via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage <NUM> may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. Electronic storage <NUM> may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). Electronic storage <NUM> may store software algorithms, information determined by processor(s) <NUM>, information received from the wireless device <NUM>, information received from second wireless device <NUM>, and/or other information that enables the wireless device <NUM> to function as described herein.

Processor(s) <NUM> may be configured to provide information processing capabilities in the wireless device <NUM>. As such, the processor(s) <NUM> may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information. Although the processor(s) <NUM> is illustrated as a single entity, this is for illustrative purposes only. In some embodiments, the processor(s) <NUM> may include a plurality of processing units and/or processor cores. The processing units may be physically located within the same device, or processor(s) <NUM> may represent processing functionality of a plurality of devices operating in coordination. The processor(s) <NUM> may be configured to execute modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> and/or other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor(s) <NUM>. As used herein, the term "module" may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.

The description of the functionality provided by the different modules <NUM>-<NUM> described below is for illustrative purposes, and is not intended to be limiting, as any of modules <NUM>-<NUM> may provide more or less functionality than is described. For example, one or more of the modules <NUM>-<NUM> may be eliminated, and some or all of its functionality may be provided by other modules <NUM>-<NUM>. As another example, the processor(s) <NUM> may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of the modules <NUM>-<NUM>.

<FIG> is a process flow diagram illustrating a method <NUM> that may be performed by a processor of a wireless device for communicating information in a PUCCH message according to various embodiments. <FIG> is a block diagram illustrating an example PUCCH configured in the method <NUM> to include a short data field according to various embodiments. With reference to <FIG>, the method <NUM> may be implemented by a processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of a wireless device (e.g., the wireless device 120a-120e, <NUM>, <NUM>, <NUM>).

Referring to <FIG>, in block <NUM>, the processor configures a PUCCH message to include an uplink message in a short data field. For example, <FIG> illustrates an example PUCCH <NUM>. The processor configures the PUCCH message <NUM> to include a short data field <NUM>. In some embodiments, the processor may configure the PUCCH message <NUM> such that the short data field <NUM> is immediately subsequent to another field, such as Ack field <NUM>. In some embodiments, the processor may configure the PUCCH message <NUM> such that the short data field <NUM> precedes one or more other data fields, data structures, or messages, such as a scheduling request (SR) field <NUM>, a first part of channel state information (CSI-<NUM>) field <NUM>, and/or a second part of channel state information (CSI-<NUM>) field <NUM>. In some embodiments, the processor may configure the short data field to include information in an uplink message that would otherwise be sent in a data channel uplink message, such as an uplink data message, or in an uplink control message other than the PUCCH. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).

In block <NUM>, the processor sends the PUCCH message including the short data field to convey the one or more uplink messages to a communication network. The processor sends the PUCCH message to a base station (e.g., the base station 110a-110d) to convey the one or more uplink messages to the communication network. In some embodiments, the one or more uplink messages may be sent to the base station. In some embodiments the one or more uplink messages may be conveyed by the communication network to another device, such as a TCP sender device. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

The method <NUM> may be repeated continuously or periodically as the processor may again perform the operations of block <NUM>.

<FIG> is a process flow diagram illustrating operations <NUM> that may be performed by a processor of a wireless device as part of the method <NUM> according to various embodiments. In some embodiments, the operations <NUM> may that enable the processor of the wireless device to generate an acknowledgment of received data according to various embodiments.

In block <NUM>, the processor may receive data in a downlink channel from a second wireless device (e.g., the wireless device 120a-120e, <NUM>, <NUM>, <NUM>). In some embodiments, the second wireless device may function as a TCP sender device using TCP to send data to the (first) wireless device. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

The processor may then perform the operations of block <NUM> (<FIG>), as described.

In block <NUM>, the processor may generate an acknowledgement message responsive to the received data. In some embodiments, the acknowledgment message may include a TCP acknowledgment (Ack) message. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).

In block <NUM>, the processor may configure the short data field to include the acknowledgement message. In some embodiments, the processor may configure the short data field (e.g., <NUM>) to include the acknowledgment message. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).

In block <NUM>, the processor may send the PUCCH message including the short data field that includes acknowledgement message to acknowledge the received data. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

<FIG> are process flow diagrams illustrating operations 600a-600d that may be performed by a processor of a wireless device as part of the method <NUM> according to various embodiments. With reference to <FIG>, the operations 600a-600d may be performed by a processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of a wireless device (e.g., 120a-120e, <NUM>, <NUM>, <NUM>).

Referring to <FIG>, following the operations of block <NUM> (<FIG>), the processor may concatenate the acknowledgment message and other information in the PUCCH message in block <NUM>. For example, the processor may concatenate the acknowledgment message with one or more of a HARQ message, a channel state indicator (CSI) message, a scheduling request (SR), or other suitable information in the PUCCH message. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).

The processor may then perform the operations of block <NUM> (<FIG>) as described.

Referring to <FIG>, following the operations of block <NUM> (<FIG>), the processor may perform a symmetric header compression on the short data field that may include the acknowledgment message (e.g., a TCP ack message) within the PUCCH message in block <NUM>. Other fields in the PUCCH message, including the HARQ Ack bits, SR bits, and CSI bits, are not compressed. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).

Referring to <FIG>, the processor may receive an instruction from a network element to enable the wireless device to configure the PUCCH message to include the acknowledgment message in block <NUM>. For example, the processor may receive an instruction from a network element, such as a base station (e.g., <NUM>), to enable the wireless device to configure the PUCCH message to include the acknowledgment message. In some embodiments, the wireless device may provide an indication to the base station that the wireless device is configured to generate and provide acknowledgment messages in an uplink control channel message. In some embodiments, the base station may send a message or an instruction to the wireless device to enable the wireless device to configure the PUCCH message to include the acknowledgment message. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

Referring to <FIG>, the processor may receive an instruction from an application executing on the wireless device to enable the wireless device to configure the PUCCH message to include the acknowledgment message in block <NUM>. In some embodiments, an application executing on the wireless device may require relatively frequent uplink transmissions. For example, a gaming application may require small, frequent uplink transmissions of user action data. Such an application may suffer from any substantial decrease in data carriage to or from the wireless device. Further, such an application may require a large amount of data to be provided via a downlink data channel (for example, video or multimedia data for a gaming application). In some embodiments, the application executing on the wireless device may send a message or an instruction enabling the wireless device to configure the PUCCH message to include the acknowledgment message. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

<FIG> is a component block diagram of a network computing device <NUM> suitable for use with various embodiments (e.g., in a base station). Such network computing devices may include at least the components illustrated in <FIG>. With reference to <FIG>, the network computing device <NUM> may include a processor <NUM> coupled to volatile memory <NUM> and a large capacity nonvolatile memory, such as a disk drive <NUM>. The network computing device <NUM> may also include a peripheral memory access device such as a floppy disc drive, compact disc (CD) or digital video disc (DVD) drive <NUM> coupled to the processor <NUM>. The network computing device <NUM> may also include network access ports <NUM> (or interfaces) coupled to the processor <NUM> for establishing data connections with a network, such as the Internet and/or a local area network coupled to other system computers and servers. The network computing device <NUM> may include one or more antennas <NUM> for sending and receiving electromagnetic radiation that may be connected to a wireless communication link. The network computing device <NUM> may include additional access ports, such as USB, Firewire, Thunderbolt, and the like for coupling to peripherals, external memory, or other devices.

<FIG> is a component block diagram of a wireless device <NUM> suitable for use with various embodiments. With reference to <FIG>, various embodiments may be implemented on a variety of wireless devices <NUM> (e.g., the wireless device 120a-120e, <NUM>, <NUM>, <NUM>) an example of which is illustrated in <FIG> in the form of a smartphone. The wireless device <NUM> may include a first SOC <NUM> (e.g., a SOC-CPU) coupled to a second SOC <NUM> (e.g., a <NUM> capable SOC). The first and second SOCs <NUM>, <NUM> may be coupled to internal memory <NUM>, <NUM>, a display <NUM>, and to a speaker <NUM>. Additionally, the wireless device <NUM> may include an antenna <NUM> for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver <NUM> coupled to one or more processors in the first and/or second SOCs <NUM>, <NUM>. The wireless device <NUM> may also include menu selection buttons or rocker switches <NUM> for receiving user inputs.

The wireless device <NUM> also may include a sound encoding/decoding (CODEC) circuit <NUM>, which digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes received sound data packets to generate analog signals that are provided to the speaker to generate sound. Also, one or more of the processors in the first and second SOCs <NUM>, <NUM>, wireless transceiver <NUM> and CODEC <NUM> may include a digital signal processor (DSP) circuit (not shown separately).

The processors of the wireless network computing device <NUM> and the wireless device <NUM> may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described below. In some mobile devices, multiple processors may be provided, such as one processor within an SOC <NUM> dedicated to wireless communication functions and one processor within an SOC <NUM> dedicated to running other applications. Software applications may be stored in the memory <NUM>, <NUM> before they are accessed and loaded into the processor. The processors may include internal memory sufficient to store the application software instructions.

<FIG> is a message flow diagram illustrating a conventional procedure <NUM> for requesting uplink resources. The conventional procedure <NUM> for requesting uplink resources to transmit data in an uplink to a base station introduces stochastic and unpredictable latency each time the wireless device initiates and uplink transmission. Such latency may degrade the performance of network applications and services, especially for latency-sensitive applications, such as video communications, network gaming, virtual reality and augmented reality application, and other suitable applications and services.

In the conventional procedure <NUM>, after data <NUM> becomes available for transmission to the base station (i.e., from a wireless device application or service), a wireless device sends a scheduling request (SR) <NUM> to a base station to request uplink resources (e.g., in a physical uplink shared channel (PUSCH)). The wireless device may transmit the SR on a PUCCH resource with a specified periodicity and offset.

The scheduling request (SR) is transmitted on a PUCCH resource with certain periodicity and offset (which may be specified by a network operator), such as <NUM>. The wireless device may receive an uplink grant <NUM> from the base station.

In the next uplink opportunity, the wireless device may send a buffer status report <NUM> to the base station. The buffer status report provides the base station with information about the data that is pending transmission from the wireless device. The base station allocates uplink resources to the wireless device based on the buffer status report and sends to the wireless device an uplink grant <NUM>. The wireless device may then send uplink data <NUM> to the base station based on the uplink grant <NUM>.

The conventional procedure <NUM> incurs latency (Time <NUM>) from the time that data <NUM> becomes available for transmission to the base station until the wireless device sends the data <NUM> to the base station. The latency of Time <NUM> may be approximately <NUM>.

<FIG> is a message flow diagram illustrating a procedure <NUM> for requesting uplink resources. After data <NUM> becomes available for transmission to the base station (i.e., from a wireless device application or service), the wireless device may configure a PUCCH message to include a buffer status report in a short data field, and may send the PUCCH message <NUM> to the base station. The wireless device may receive an uplink grant <NUM> from the base station based on the buffer status report included in the PUCCH message <NUM>. The wireless device may then send uplink data <NUM> to the base station based on the uplink grant.

The procedure <NUM> incurs latency (Time <NUM>) from the time that data <NUM> becomes available for transmission to the base station until the wireless device sends the uplink data <NUM> to the base station. The latency of Time <NUM> may be substantially shorter than the latency Time <NUM> (<FIG>). Further, the PUCCH message is highly robust, and may reliably transport the buffer status report to the base station.

<FIG> is a process flow diagram illustrating a method <NUM> that may be performed by a processor of a wireless device for communicating an uplink data status in a PUCCH message according to various embodiments. <FIG> is a block diagram illustrating an example PUCCH configured in the method 900a to include a buffer status report according to various embodiments. With reference to <FIG>, the method <NUM> may be implemented by a processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of a wireless device (e.g., the wireless device 120a-120e, <NUM>, <NUM>, <NUM>).

In determination block <NUM>, the processor may determine whether a PUCCH occasion will occur before a scheduling request occasion. Means for performing functions of the operations in determination block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

In response to determining that a PUCCH occasion will not occur before a scheduling request occasion (i.e., determination block <NUM> = "No"), the processor may use a scheduling request procedure in block <NUM>. In some embodiments, the processor may send a scheduling request to a base station to request uplink resource (e.g., the scheduling request <NUM>, <FIG>).

In response to determining that a PUCCH occasion will occur before a scheduling request occasion (i.e., determination block <NUM> = "Yes"), the processor may configure a PUCCH message to include a buffer status report in a short data field in block <NUM>. For example, <FIG> illustrates an example PUCCH <NUM>. The processor may configure the PUCCH message <NUM> to include a buffer status report <NUM>. In some embodiments, the processor may configure the PUCCH message <NUM> such that the buffer status report <NUM> is immediately subsequent to another field, such as Ack field <NUM>. In some embodiments, the processor may configure the PUCCH message <NUM> such that the buffer status report <NUM> precedes one or more other data fields, data structures, or messages, such as a first part of channel state information (CSI-<NUM>) field <NUM>, and/or a second part of channel state information (CSI-<NUM>) field <NUM>.

In various embodiments, the PUCCH is expected to be available with high probability for (at least) HARQ feedback during latency sensitive applications such as video communications (e.g., video calls, videoconferencing), online gaming, virtual reality and augmented reality applications, and other suitable applications, due at least in part to high downlink activity expected for such applications. Further, the high robustness of the PUCCH message makes the PUCCH a highly reliable transport for the buffer status report. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).

Returning to <FIG>, in block <NUM>, the processor may send the PUCCH message including the buffer status report to convey the buffer status report to a base station. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

In block <NUM>, the processor may receive an uplink grant from the base station based on the buffer status report conveyed in the PUCCH message. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

In block <NUM>, the processor may send uplink data to the base station during the granted uplink. Means for performing functions of the operations in block <NUM> may include the processor (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to a wireless transceiver (e.g., <NUM>, <NUM>).

The processor may again perform the operations of determination block <NUM> from time to time.

As used in this application, the terms "component," "module," "system," and the like are intended to include a computer-related entity, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, which are configured to perform particular operations or functions. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a wireless device and the wireless device may be referred to as a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one processor or core and/or distributed between two or more processors or cores. In addition, these components may execute from various non-transitory computer readable media having various instructions and/or data structures stored thereon. Components may communicate by way of local and/or remote processes, function or procedure calls, electronic signals, data packets, memory read/writes, and other known network, computer, processor, and/or process related communication methodologies.

A number of different cellular and mobile communication services and standards are available or contemplated in the future, all of which may implement and benefit from the various embodiments. Such services and standards include, e.g., third generation partnership project (3GPP), long term evolution (LTE) systems, third generation wireless mobile communication technology (<NUM>), fourth generation wireless mobile communication technology (<NUM>), fifth generation wireless mobile communication technology (<NUM>), global system for mobile communications (GSM), universal mobile telecommunications system (UMTS), 3GSM, general packet radio service (GPRS), code division multiple access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), enhanced data rates for GSM evolution (EDGE), advanced mobile phone system (AMPS), digital AMPS (IS-<NUM>/TDMA), evolution-data optimized (EV-DO), digital enhanced cordless telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), wireless local area network (WLAN), Wi-Fi Protected Access I & II (WPA, WPA2), and integrated digital enhanced network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and/or content messages. It should be understood that any references to terminology and/or technical details related to an individual telecommunication standard or technology are for illustrative purposes only, and are not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

Various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. Further, the claims are not intended to be limited by any one example embodiment. For example, one or more of the operations of the methods <NUM>, <NUM>, and 600a-600d may be substituted for or combined with one or more operations of the methods <NUM>, <NUM>, and 600a-600d.

The hardware used to implement various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, DISCRETE hardware components, or any combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

Claim 1:
A method (<NUM>) performed by a wireless device for communicating an uplink data status in a physical uplink control channel, PUCCH, message (<NUM>) in a 3GPP system, comprising:
determining whether a PUCCH occasion will occur before a scheduling request occasion;
configuring (<NUM>) the PUCCH message (<NUM>) to include a buffer status report (<NUM>) including information about data that is pending to be sent to a base station in a short data field (<NUM>) in response to determining that the PUCCH occasion will occur before the scheduling request occasion, the short data field (<NUM>) being a field added to the PUCCH message; and
sending (<NUM>; <NUM>) the PUCCH message (<NUM>) including the buffer status report (<NUM>) to convey the buffer status report (<NUM>) to the base station.