WO2018080561A1 - Buffer status reporting in 5g nr-things sidelink communications - Google Patents

Abstract

Systems and methods of providing a BSR from a tUE to a nUE are generally described. Contents of different types of BSRs are described, including a BSR-in-ACK, in which the BSR is transmitted in a HARQ ACK/NACK, and a BSR-in-PDU, in which the BSR is transmitted in a PDU or random access process. The BSR has one or more fields. Each field indicates the range for a different type of URLLC and non-URLLC data buffered for transmission to the nUE. Triggers and configurations for BSR transmission and trigger cancelation are provided to the tUE via RRC signaling.

Description

BUFFER STATUS REPORTING IN 5G NR-THINGS SIDELINK COMMUNICATIONS PRIORITY CLAIM

[0001J This application claims the benefit of priority to United States

Provisional Patent Application Serial No. 62/412,721 , filed October 25, 2016, entitled "BUFFER STATUS REPORTING IN 5G NR-THINGS SIDELINK COMMUNICATION S," which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002 J Embodiments pertain to radio access networks. Some embodiments relate to wearable devices in various cellular and wireless local area network (WLAN) networks, including Third Generation Partnership Project Long Term Evolution (3GPP LTE) networks and LTE advanced (LTE-A) netw orks as well as 4^th generation (4G) networks and 5^th generation (5G) networks. Some embodiments relate to 5G wearable or other "things" devices and network interactions, in particular handling of user and control plane data in side link communications.

BACKGROUND

[0003] The use of 3GPP LTE systems (including both LTE and LTE-A systems) has increased due to both an increase in the types of devices user equipment (UEs) using network resources as well as the amount of data and bandwidth being used by various applications, such as video streaming, operating on these UEs. For example, the growth of network use by Internet of Things (IoT) UEs, which include machine type communication (MTC) devices such as sensors and may use machine-to-machine (M2M) communications, has severely strained network resources. New 3GPP standard releases related to the next generation network (5G) are taking into account the massive influx of low- data, high-delay and low power transmissions. [0004] One type of user-based IoT devices developed recently whose popularity has exploded is "tilings'¹ user equipment (tUE), such as wearable devices, in addition to one or more network UEs (nUE). Examples of wearable devices include fitness trackers, smart watches, and smart glasses. Wearable devices typically have lower processing capability, a small batteiy capacity, and a low internal memory capacity. In terms of deployment, each user may carry multiple wearable devices, and may be located in a highly -dense populated situation with other people carrying one or more other wearable devices and nUEs. Unlike many MTC IoT devices, tUEs may have a mobility similar to that of nUEs and limited functionality compared to the nUEs, independent of the type of tUE. The sidelink communication in the 5G network between a tUE and nUE, however, remains to be determined due at least in part to the vast changes in design of the 5G network. BRIEF DESCRIPTION OF THE FIGURES

[0005] In the figures, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The figures illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

[0006] FIG. 1 is a block diagram of a system architecture for supporting wearable devices in accordance with some embodiments.

[0007] FIG. 2 illustrates components of a communication device in accordance with some embodiments.

Θ008] FIG. 3 illustrates a block diagram of a communication device in accordance with some embodiments.

[0009] FIG. 4 illustrates another block diagram of a communication device in accordance with some embodiments.

[0010] FIG. 5 illustrates a protocol stack in accordance with some embodiments.

[0011] FIG. 6 illustrates a flowchart of a buffer status reporting (BSR) method in accordance with some embodiments. [0012] FIGS. 7A-7C illustrate BSR control elements (CEs) in accordance with some embodiments.

[0013] FIGS. 8A-8F illustrate various formats/cases of a BSR-in-Data packet data unit (PDU).

[0014] FIGS. 9A and 9B illustrate downlink and uplink subframe structures in accordance with some embodiments.

DETAILED DESCRIPTION

[0015] The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them.. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.

[0016] FIG. 1 is a block diagram of a system architecture 100 for supporting 5G things (such as wearable) devices. As shown, the system architecture 100 includes a network user equipment (nUE) 1 10, one or more things user equipment (tUEs) 120a, 120b, 120c, an evolved universal terrestrial radio access network (E-UTRAN) base station (BS, also referred to as an evolved NodeB (eNB)) or 5G base station 130, and an evolved packet core (EPC) or 5G core 140. The nUE 110 and the tUEs 120 together form, a personal area network (PAN) 150 or side link cell. The EUTRAN thus may include eNBs 130 that provide user plane and control plane protocol terminations towards the nUE 110. The eNBs 130 may be connected by means of the X2 interface. The eNBs 130 may also be connected to a Mobility Management Entity (MME) via a S l-MME and to a Serving Gateway (S-GW) via a Sl-U.

[0017] The nUE 110 may be any user equipment capable of

communicating with the base station 130 via an air interface. According to some examples, the nUE 110 may be a mobile phone, a tablet computer, a wearable device such as a smart watch, etc. According to some examples, the nUE may be a tUE that is capable of communicating with the base station 130 and has sufficient batten' life (e.g., greater than 30%, 50%, 75%, 90% of the maximum amount of battery power etc.). Hie nUE 110 may have a full infrastructure network access protocol and full control and user plane (C/U-dlane) functions. As shown, the nUE 110 may communicate with the base station 130 via a Xu-d (direct) air interface.

[0018] Each tUE 120 may include a wireless interface (Xu-d or Xu-s) for communicating within the PAN 150. The tUE 120 may communicate with the nUE 110 or another tUE 120 through the Xu-s (sidelink) intra-PAN air interface. The tUE 120 may include, for example, smart watches, smart glasses, smart headphones, fitness sensors, movement trackers, sleep sensors, etc. In some embodiments, the tUE 120 may also communicate directly with the base station 130 via a Xu-d air interface. In some embodiments, the tUE 120 may be unable to communicate directly with the base station 130. The nUE 110 may act as a master UE in a sidelink cell formed by the nUE 110 and associated tUEs 120. The tUE 120 may have a full sidelink protocol stack and may or may not have standalone direct link protocol stack. The tUE 120 may act as a slave UE in the side link cell.

[0019] The base station 130 may be a base station of a cellular network.

The base station 130 is may be an eNB in a LTE cellular network or a 5G Radio Access Network (RAN) in a next generation (5G) network. In the latter case, the 5G RAN may be a standalone base station or a booster cell anchored to an eNB. The base station 130 may communicate with a core network 140 (EPC for LTE or 5G core for 5G) using an SI interface. Some aspects of the subject technology are directed to defining the air interface between the base station and the PAN of the nUE 1 10 and the tUEs 120, while other aspects are directed to defining the intra-PAN air interface for enabling low power operation with diverse traffic and application requirements.

[0020] Some aspects of the subject technology may be implemented in conjunction with a LTE network, and, in some cases, leverages device-to-device (D2D) and machine -type communications (MTC) technology. However, for connectivity techniques, aspects of the subject technology address high-density scenarios. For LTE-D2D, some aspects of the subject technology enable PAN- speciflc identity, unicast in intra-PAN communication, uplink and downlink features, and operation in unlicensed bands. For LTE-MTC, some aspects of the subject technology provide support for diverse traffic, including high rate traffic and low latency traffic.

[0021] The base station 130 may be a macro base station or a smaller base station (micro, pico, nano) that may terminate the air interface protocol . In some embodiments, the base station 130 may fulfill various logical functions for the RAN including, but not limited to, RNC (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In accordance with embodiments, UEs 120 may be configured to communicate orthogonal frequency division multiplexed (OFDM) communication signals with the base station 130 over a multicarrier communication channel in accordance with an OFDMA communication technique. The OFDM signals may comprise a plurality of orthogonal subcarners. In other embodiments, such as those related to 5G systems, non-OFDM signals may be used in addition or instead of OFDM signals.

[0022] The S I interface may be the interface that separates the RAN 130 and the core network 140. The S I interface may be split into two pasts: the Sl- U, which may carry traffic data between base stations of the RAN 130 and other elements of the core network, such as a serving GW, and the S l-MME, which may be a signaling interface between the RAN 130 and an MME.

[0023] FIG. 2 illustrates components of a communication device in accordance with some embodiments. The communication device 200 may be a UE, eNB or other network component as described herein. The communication device 200 may be a stationary, non-mobile device or may be a mobile device. In some embodiments, the UE 200 may include application circuitry 202, baseband circuitry 204, Radio Frequency (RF) circuitry 206, front-end module (FEM) circuitry 208 and one or more antennas 210, coupled together at least as shown. At least some of the base band circuitry 204, RF circuitry 206, and FEM circuitry 208 may form a transceiver. In some embodiments, other network elements, such as the MME may contain some or all of the components shown in FIG. 2.

[0024] The application or processing circuitry 202 may include one or more application processors. For example, the application circuitiy 202 may include circuitry such as, but not limited to, one or more single-core or multi- core processors. The processor(s) may include any combination of general- purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage and may be configured to execute snstmciions stored in the memory/storage to enable various applications and/or operating systems to ran on the system.

[0025] The baseband circuitiy 204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitiy 204 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 206 and to generate baseband signals for a transmit signal path of the RF circuitiy 206. Baseband processing circuity 204 may interface with the application circuitiy 202 for generation and processing of the baseband signals and for controlling operations of the RF circuitiy 206. For example, in some embodiments, the baseband circuitiy 204 may include a second generation (2G) baseband processor 204a, third generation (3G) baseband processor 204b, fourth generation (4G) baseband processor 204c, and/or other baseband processor(s) 204d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 5G, etc.). The baseband circuitry 204 (e.g., one or more of baseband processors 204a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitiy 206. The radio control functions may include, but are not limited to, signal modulation/demodulation,

encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 204 may include FFT, preceding, and/or constellation mapping/demapping functionality . In some embodiments, encoding/decoding circuitiy of the baseband circuitry 204 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. [0026] In some embodiments, the baseband eireuitiy 204 may include elements of a protocol stack such as, for example, elements of an Evolved UT AN (EUTRA ) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) elements, and/or Non- Access Stratum (NAS) elements. A central processing unit (CPU) 204e of the baseband circuitry 204 may be configured to ran elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers, and/or NAS. In some embodiments, rather than the layers described above, the protocol layers shown in FIG. 5 may be implemented in the baseband circuitry 204 and ran by the CPU 204e. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 204f. The audio DSP(s) 204f ma ^¬ be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 204 and the application circuitr ' 202 may be

implemented together such as, for example, on a system on a chip (SOC).

[0027] In some embodiments, the baseband circuitry 204 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 204 may support communication with an EUTRAN and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry. In some embodiments, the device can be configured to operate in accordance with communication standards or other protocols or standards, including Institute of Electrical and Electronic Engineers (IEEE) 802.16 wireless technology (WiMax), IEEE 802.11 wireless technology (VViFi) including IEEE 802.11 ad, which operates in the 60 GHz millimeter wave spectrum, various other wireless technologies such as global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE radio access network (GERAN), universal mobile telecommunications system (UMTS), UMTS terrestrial radio access network (I THA N ), or other 2G, 3G, 4G, 5G, etc. technologies either already developed or to be developed.

0028J RF circuitry 206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 206 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 208 and provide baseband signals to the baseband circuitr - 204. RF circuitry 206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 204 and provide RF output signals to the FEM circuitry 208 for transmission.

[0029] In some embodiments, the RF circuitry 206 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 206 may include mixer circuitry 206a, amplifier circuitry 206b and filter circuitry- 206c. The transmit signal path of the RF circuitry 206 may include filter circuitry 206c and mixer circuitry 206a. RF circuitry 206 may also include synthesizer circuitry 206d for synthesizing a frequency for use by the mixer circuitry 206a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 206a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 208 based on the synthesized frequency provided by synthesizer circuitry 206d. The amplifier circuitry 206b may be configured to amplify the down-converted signals and the filter circuitry- 206c may be a low -pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 204 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although tins is not a requirement. In some embodiments, mixer circuitry 206a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect. [0030] In some embodiments, the mixer circuitiy 206a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 206d to generate RF output signals for the FEM circuitry 208. The baseband signals may be provided by the baseband circuitiy 204 and may be filtered by filter circuitry 206c. The filter circuitry 206c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

[0031] In some embodiments, the mixer circuitiy 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitiy 206a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may be configured for super-heterodyne operation .

[0032] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 204 may include a digital baseband interface to communicate with the RF circuitry 206.

[0033] In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0034] In some embodiments, the synthesizer circuitry 2()6d may be a fractional -N synthesizer or a fractional N/N+l synthesizer, altliough the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 206d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0035] The synthesizer circuitry 206d may be configured to synthesize an output frequency for use by the mixer circuitrv' 206a of the RF circuitry- 206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 206d may be a fractional N/N+l synthesizer.

[0036] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitrv' 204 or the applications processor 202 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a lookup table based on a channel indicated by the applications processor 202.

[0037] Synthesizer circuitry 206d of the RF circuitry 206 may include a divider, a delay -locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up in to Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0038] In some embodiments, synthesizer circuitry 206d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the earner frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (flo). In some embodiments, the RF circuits"}' 206 may include an IQ/polar converter. [0039] FEM circuitry 208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 206 for further processing. FEM circuitry 208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 206 for transmission by one or more of the one or more antennas 2 0.

004Θ] In some embodiments, the FEM circuitry 208 may include a

TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 206). The transmit signal path of the FEM circuits"}' 208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 210.

[0041] In some embodiments, the communication device 200 may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or input/output (I/O) interface as described in more detail below. In some embodiments, the communication device 200 described herein may be part of a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless

communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive and/or transmit information wirelessly. In some embodiments, the communication device 200 may include one or more user interfaces designed to enable user interaction with the system and/or peripheral component interfaces designed to enable peripheral component interaction with the system. For example, the communication device 200 may include one or more of a keyboard, a keypad, a touchpad, a display, a sensor, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, one or more antennas, a graphics processor, an application processor, a speaker, a microphone, and other I/O components. The display may be an LCD or LED screen including a touch screen . The sensor may include a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

[0042] The antennas 210 may comprise one or more directional or omnidirectional antennas, including, for example, dipoie antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some multiple-input multiple-output (MIMO) embodiments, the antennas 210 may be effectively- separated to take advantage of spatial diversity and the different channel characteristics that may result.

[0043] Although the communication device 200 is illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements.

[0044] Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instractions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include readonly memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media. Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device. Θ045] FIG. 3 is a block diagram of a communication device in accordance with some embodiments. The device may be a UE, for example, such as the UE shown in FIG. 1. The physical layer circuitry 302 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals. The communication device 300 may also include medium access control layer (MAC) circuitry 304 for controlling access to the wireless medium. The communication device 300 may also include processing circuitry 306, such as one or more single-core or multi-core processors, and memory 308 arranged to perform the operations described herein. The physical layer circuitry 302, MAC circuitry 304 and processing circuitry 306 may handle various radio control functions that enable communication with one or more radio networks compatible with one or more radio technologies. The radio control functions may include signal modulation, encoding, decoding, radio frequency shifting, etc. For example, similar to the device shown in FIG. 2, in some embodiments, communication may be enabled with one or more of a WMAN, a WLAN, and a WPAN. In some embodiments, the communication device 300 can be configured to operate in accordance with 3 GPP standards or other protocols or standards, including WiMax, WiFi, WiGig, GSM, EDGE, GERAN, UMTS, UTRAN, or other 3G, 3G, 4G, 5G, etc. technologies either already developed or to be developed. The communication device 300 may include transceiver circuitry 312 to enable communication with other external devices wirelessly and interfaces 314 to enable wired communication with other external devices. As another example, the transceiver circuitry 312 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range.

[0046] The antennas 301 may comprise one or more directional or omnidirectional antennas, including, for example, dipoie antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some MIMO embodiments, the antennas 301 may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.

[0047] Although the communication device 300 is illustrated as having several separate functional elements, one or more of the functional elements may^¬ be combined and may be implemented by combinations of software-configured elements, such as processing elements including DSPs, and/or other hardware elements. For example, some elements may comprise one or more

microprocessors, DSPs, FPGAs, AS I Cs, RFICs and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements. Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer- readable storage device, which may be read and executed by at least one processor to perform the operations described herein.

[0048] FIG. 4 illustrates another block diagram of a communication device in accordance with some embodiments. In alternative embodiments, the communication device 400 may operate as a standalone device or may be connected (e.g., networked) to other communication devices. In a networked deployment, the communication device 400 may operate in the capacity of a server communication device, a client communication device, or both in server- client network environments. In an example, the communication device 400 may act as a peer communication device in peer-to-peer (P2P) (or oilier distributed) network environment. The communication device 400 may be a UE, eNB, PC, a tablet PC, a STB, a PDA, a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by that communication device. Further, while only a single

communication device is illustrated, the term "communication device" shall also be taken to include any collection of communication devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a sen/ice (SaaS), other computer cluster configurations. [0049] Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may^¬ be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform, specified operations. In an example, the software may reside on a communication device readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

[0050] Accordingly, the term "module" is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general -purpose hardware processor configured using software, the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

[0051 ] Communication device (e.g., computer system) 400 may include a hardware processor 402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a mam memory 404 and a static memory 406, some or all of which may communicate with each other via an interlink (e.g., bus) 408. The

communication device 400 may further include a display unit 410, an alphanumeric input device 412 (e.g., a keyboard), and a user interface (UI) navigation device 414 (e.g., a mouse). In an example, the display unit 410, input device 412 and UI navigation device 414 may be a touch screen display. The communication device 400 may additionally include a storage device (e.g., drive unit) 4 6, a signal generation device 418 (e.g., a speaker), a network interface device 420, and one or more sensors 421 , such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The communication device 400 may include an output controller 428, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

[0052] The storage device 416 may include a communication device readable medium 422 on which is stored one or more sets of data structures or instructions 424 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 424 may also reside, completely or at least partially, within the main memory 404, within static memory 406, or within the hardware processor 402 during execution thereof by the communication device 400. In an example, one or any combination of the hardware processor 402, the main memory 404, the static memory 406, or the storage device 416 may constitute communication device readable media.

[0053] While the communication device readable medium 422 is illustrated as a single medium, the term "communication device readable medium" may include a single medium, or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 424.

[0054] The term ^"'communication device readable medium" may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 400 and that cause the communication device 400 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting communication device readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of communication device readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices: magnetic disks, such as internal hard disks and removable disks:

magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-RDM disks. In some examples, communication device readable media may include non-transitory communication device readable media. In some examples, communication de vice readable media may include communication device readable media that is not a transitory propagating signal.

[0055] The instructions 424 may further be transmitted or received over a communications network 426 using a transmission medium via the network interface device 420 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks). Plain Old Telephone (POTS) networks, and wireless data networks (e.g., IEEE 802.11 family of standards known as WiFi®, IEEE 802.16 family of standards known as WrMax®), IEEE 802.15.4 family of standards, a LTE family of standards, a UMTS family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device 420 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 426. In an example, the network interface device 420 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) techniques. In some examples, the network interface device 420 may wirelessly communicate using Multiple User MIMO techniques. The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the communication device 400, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

[0056] As above, in certain embodiments, a tUE such as a wearable device or vehicle-embedded device may be temporarily or permanently constrained to communicate with the EUTRAN through a nUE (also referred to as a controller UE or a scheduler UE). Several tUEs may he associated with a particular nUE to form a PAN. A large number of nUEs may be located in a particular geographical region served by a single EUTRAN. Each nUE may be associated with a different PAN, which may create a high density network scenario. The RAN may furthermore assign a common resource pool for wearable communication. This resource pool may be shared among all of the PANs in the geographical area and within each PAN on a contention-based resource access basis. Each nUE may have two higher layer protocol stacks, one for the Xu-s interface with the tUE and one for the Xu-d interface with the EUTRAN. Dependent on the embodiment, the tUEs may have the same two higher layer protocol stacks or may have a single higher layer protocol stack for one for the Xu-s interface with the nUE.

[0057J Resource handling by the nUE may involve several procedures to make challenging decisions such as: (i) uplink (UL) versus downlink (DL) subframes allocations as the considered system over Xu-s interface works as a time division duplexing (TDD) system; (ii) scheduling of multiple tUEs for DL transmission in a DL subframe; and (iii) scheduling of multiple tUEs for UL transmission in an UL subframe. All these decisions and selections made by the nUE may depend at least in part on the amount and type of data traffic waiting for UL and/or DL transmission.

[0058] In addition to retaining information about the amount and types of data traffic associated with direct transmission from the tUEs however, a mechanism that may include multiple procedures and signaling may be used to enable the nUE to receive information about the amount and type of UL traffic waiting for retransmission at various tUEs. Such a mechanism may be used by the tUEs as it may enable the tUE to ask for UL resource and services for UL transmissions with the nUE. To this end a detailed mechanism, referred to herein as a buffer status reporting (BSR) mechanism, may enable the tUE to send or the nUE to acquire updated information about the amount and types of UL traffic waiting for transmission or retransmission at the tUE. As used herein retransmission data is data to be retransmitted at the tSL-HL PD U level for ARQ retransmission. [0059] FIG. 5 illustrates a protocol stack in accordance with some embodiments. The protocol stack may be provided in any of the nUEs or tUEs described in FIGS. 1-4. The higher layer protocol stack (tSL-HL) 504 may refer primarily to the protocol layers between the PHY (tSL-PHY) 506 and

IP/ Application layers 502 in the user plane (UP) and between the tSL-PHY 506 and tSL radio resource control layer (tSL-RRC) 508 for the control plane (CP). The tSL-HL 504 may refer to one or more of the MAC, RLC and PDCP layers of legacy LTE protocol layers.

[0060] The protocol stack at the tUE may be used during various BSR procedures. FIG. 6 illustrates a flowchart of a buffer status reporting (BSR) method in accordance with some embodiments. The method may be perfonned by any tUE shown in FIGS. 1-4. The procedures may include generation, maintaining and cancellation of triggers for BSR transmission, generation of a BSR, and transmission of the BSR. At operation 602, one or more BSR transmission triggers may be generated. The types of BSR transmission triggers and conditions for generating a BSR trigger are provided in more detail below.

[0061] Generation of the BSR at operation 604 may include a number of separate operations. The separate operations may include generation of BS content (also referred to herein as a BSR message or a BSR control element (CE)), defining different types of BSR messages/CEs to handle regular new/retransmission data as well as Ultra-High Reliability and Low Latency Communication (URLLC) and Mission Critical (MC) new/retransmission data, and defining various fields for each BSR message/CE type. Hie types of data as used herein thus include new and retransmission data, MC/URLLC (also referred to herein merely as URLLC for convenience) and non -MC URLLC data, and control plane and user plane data. Thus, different applications may provide the same or different types of data. Generation of the BSR is provided in more detail below.

[0062] After BS generation, the tUE may at operation 606 transmit the BSR. Transmission of the BSR may include transmission of the BSR in a UL Data PDU, transmission of the BSR in an acknowledgment (ACK) for a DL HARQ Process and invocation of a Random. Access (RA) process and transmission of the BSR in a RA message. The RA may be contention-based, for example, the RA message may be a Contention Resolution RA PDU. The conditions under which the BSR is transmitted is provided in more detail below.

[0063] After transmission of the BSR, at operation 608 one or more of the BSR triggers may be cancelled. As provided in more detail below, cancellation of a specific BSR trigger may be dependent on the type of trigger and what was transmitted in operation 606.

[0064] In general, the above BSR mechanism, may enable the tUE to send, and the nUE to acquire, updated information about the amount and types of UL traffic waiting for transmission or retransmission at the tUE. An efficient BSR mechanism may be used by the nUE for effective resource scheduling among the tUEs in the PAN in order to maximize resource utilization, enhance the user experience among the tUEs in the PAN associated with the nUE, treat the tUEs based on the priorities of different types of data and tUEs, impro ve fairness among the tUEs, and improve overall system performance. The nUE may perform a scheduling and resource assignment procedure based on the BSR information. The scheduling and resource assignment may include a determination of the UL/DL subframe rati o, scheduling of one or more tUEs for DL transmission in a DL subframe, and scheduling of one or more tUEs for UL transmission in an UL subframe as major functionalities.

[0065] Various pieces of information from tUEs may be used by the nUE for scheduling and resource assignment. This information may include the amount of regular (non-MC/non-URLLC) UL data at each tUE, as well as the amount of MC/URLLC UL data for a new transmission or retransmission at each tUE. The amount of regular data indicated may include the total amount of each of: non-MC/non-URLLC data, new transmission data, retransmission data, user plane data, user plane new data, user plane retransmission data, control plane data, control plane new data, and control plane retransmission data. The non-MC/non-URLLC data may include the sum of all types of user and control plane new and retransmission data,. The new transmission data may include the sum of all types of user and control plane new transmission data and the retransmission data may include the sum of all types of user and control plane retransmission data. The user plane data may include the sum of user plane new and retransmission data and the control plane data may include the sum of control plane new and retransmission data. Tlie user plane new data, user plane retransmission data, control plane new data, and control plane retransmission data may contain the sum. of the respective type of data,

Θ066] Tlie BSR mechanism may be used when transmission of the information from the tUE to the nUE is to be performed. Tlie BSR mechanism may, as above, generate, maintain and cancel triggers for BSR transmission, generate a BSR, and transmit the BSR.

[0067] Two main formats may be used for BSR CEs: a BSR-in-ACK CE and a BS -in-Data PDU. FIGS. 7A-7C illustrate BSR control elements (CEs) in accordance with, some embodiments. The BSR-in-ACK CE may be of fixed small size, such as a few bits. In some embodiments, the size of the BSR-in- ACK CE may be 4 bits (16 total values), and, in particular, the first 4 bits of the octet may contain the BSR-in-ACK CE. The BSR-in-ACK CE may be targeted to be sent in an ACK/NACK message in the ACK channel of a downlink subframe. The BSR-in-ACK CE can be used to inform the nUE about arrival of MC URLLC data in a downlink subframe at the tUE. In particular, the BSR-in- ACK CE may indicate the arrival by inserting a BSR-in-ACK in the

ACK NACK message of a DL HARQ process (DL data transmission process). BSR-in-ACK can also provide tlie buffer size of other non-MC/non-URLLC data as described in Tables 1 and 2 below.

TABLE I ; BSR-in-ACK Fields

Table 2: Mapping of BSR-in-ACK to the Buffet Size ieveis. BSR-in-ACK Index (4 bits) Buffer Size (BS) value [bytes]

0000 (0) BS ■ ⁾

1 0 < BS <= 22

22 < BS <= 75

3 75< BS <= 150

4 150 < BS <= 375

5 375 < BS <=922

6 922 < BS <= 1822

1822 < BS <=3822

8 3822 < BS <=6074

9 6074 < BS <=13888

10 13888 < BS <=31752

1 1 31752 < BS <=72598

12 72598 < BS <=165989

13 165989 < BS <=3000000

14 BS > 3000000

[0068] As shown in Tables 1 and 2 and in FIGS. 7B and 7C, when the

BSR-in-ACK CE has a BSR index = 1 111, the value of the index may notify the nUE that MC/URLLC UL data is pending in buffer for a new transmission or a retransmission. A BSR-in-ACK CE having an BSR Index from 0000 to 1110 (0-14) may indicate to the nUE the tentative total data amoimt in the UL buffer of the tUE pending for (re)transmission. Each BSR Index may be mapped to a range of buffer sizes. Although an example of the BSR index and corresponding buffer sizes is provided in Table 2, other buffer size ranges may be used in the indexes. As the number of BSR Index values are limited, a range of sizes are indicated by each index, with granularity changing with increasing amount of data. A smaller granularity for smaller buffer sizes provides more accurate buffer size information to the nUE (and eNB). A larger granularity may be provided for larger buffer size as the nUE may not provide a grant for the UL data in one TTL For a smaller buffer size, the granularity may be selected based on resource allocation granularity (e.g., 1 PRB, 2 PRBs) and how many bits each PRB can cany. The amount of data in each PRB may vary with MCS, each PRB typically being able to carry 22 bytes to 75 bytes. The buffer range represented by each index value may thus be a multiple of the possible bytes each PRB can carry. In other embodiments, the BSR size range indicated by each index value may be selected randomly, but without any gap between two consecutive ranges.

[0069] The BSR-in-PDU may be a general purpose BSR carrying detailed information of buffer sizes of various types of data at the tUE. FIGS. 8A-8F illustrate various foirnats/cases of a BSR-in-Data packet data unit (PDU). The BSR-in-Data PDU may be of longer size than the BSR-in-ACK CE, for example, 5 or more bits. The BSR-in-Data PDU may be generally transmitted in a data PDU or in a Random Access message, in either of which a greater number of bits for BSR reporting can be accommodated. As shown in FIGS. 8A-8F, the BSR-in-Data PDU may have multiple fields carrying different information. Each field may carry', for example, buffer sizes of different types of traffic. Each field may use a 5 bit BSR-in-Data PDU index to represent the associated buffer size. Table 3 shows various possible content/fields that can be present in a BSR- in-Data PDU. Table 4 shows a BSR-in-Data PDU Index to buffer size level mapping.

TABLE 3: Description of BSR-in-Data PDU Fields

Field 3: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of CP data {sum of all types of CP new arsd retransmission data)

0011 MC/URLLC Data with following field:

Field 1: 5 bit BSR-in-Data PDU Index Field - may indicate tentative size of MC URLLC data {new + retransmission)

Then, non-MC/non-URLLC Data with following fields:

Field 2: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of new data (sum of all types of non-MC/non-URLLC UP and CP new data)

Field 3: 5 bits BSR-in-Data PDU Index field - may indicate tentative total amount of retransmission data (sum of all types of non-MC/non- URLLC UP and CP retransmission data)

0100 MC/URLLC Data with following field:

Field 1: 5 bit BSR-in-Data PDU Index Field - may indicate tentative size of MC/URLLC data (new + retransmission)

Then, non-MC/non-URLLC Data with following fields:

Field 2: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of non-MC/non-URLLC UP new data (sum of all ty pes of non-MC/non-URLLC UP new data)

Field 3 : 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of non-MC/non-URLLC UP retransmission data (sum of all tvpes of non-MC/non-URLLC UP retransmission data)

Field 4: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of CP new data (sum of ail types of CP new data) Field 5: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of CP retransmission data (sum of all types of CP retransmission data)

0101 - Reserved for future use

0111

1000 No MC/URLLC Data available to report.

Non-MC/non-URLLC Data with following fields:

Field 1 : 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of non-MC/non-URLLC data (sum of all types non- MC/non-URLLC UP and CP new and retransmission data)

1001 No MC/URLLC Data available to report,

Non-MC/non-URLLC Data with following fields:

Field 1: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of non-MC/non-URLLC UP data (sum of all types of non- MC/non-URLLC UP new and retransmission data) Field 2: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of CP data {sum of all types of CP new arsd retransmission data)

1010 No MC/URLLC Data available to report,

Non-MC/non-URLLC Data with follo wing fields:

Field 1: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of non-MC/non-URLLC new data (sum of all types of non-MC/non-URLLC UP arsd CP new data)

Field 2: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of non-MC/non-URLLC retransmission data (sum of all types of non-MC/non-URLLC UP and CP retransmission data)

1011 No MC/URLLC Data available to report,

Non-MC/non-URLLC Data with following fields:

Field 1: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of non-MC/non-URLLC UP new data (sum of all ty pes of non-MC/non-URLLC UP new data)

Field 2: 5 bit BSR-in-Data PDU index Field - may indicate tentative total amount of non-MC/non-URLLC UP retransmission data (sum of all types of non-MC/non-URLLC UP retransmission data)

Field 3: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of CP new data (sum of all types of CP new data) Field 4: 5 bit BSR-in-Data PDU Index Field - may indicate tentative total amount of CP retransmission data (sum of all ty pes of CP retransmission data)

1100- Reserved for future use

1111

TABLE 4: Buffer Size levels for BSR-in-Data PDU

BSR-in-Data Buffer Size (BS) BSM-in-Bata Buffer Size (BS) value

PDU Index (5 value [bytes] PDU Index (5 [bytes]

bits) bits)

0 BS = 0 16 4940 <BS<- 6074

1 0 BS <= 22 17 6074 <BS<= 9185

2 22 <BS 45 18 9185 < BS<- 33888

3 45< BS <= 75 19 13888 <BS<= 20999

4 75<BS<-97 20 20999 <BS<= 31752

5 97 < BS <= 129 21 31752 <BS<= 48012

6 129 BS 150 22 48012 <BS<- 72598

150<BS<==225 23 72598 <BS<= 109774

8 225< BS <=^■ 375 24 109774 <BS<- 165989

9 375 <BS<= 600 25 165989 < BS <= 250990

10 600<BS<= 922 26 250990 < BS<- 379519

11 922 < BS <=== 1244 379519 <BS <= 573866

12 1244<BS<= 1822 28 573866 < BS <= 867737

13 1822 < BS <= 2650 29 867737 <BS<= 1312097

14 2650 < BS <= 3822 30 1312097 <BS<= 3000000

15 3822 < BS <= 4950 31 BS > 3000000

[0070J The BSR-in-Data PDU may contain multiple fields, including a

BSR-in-Data PDU Control Element (indicate in FIGS.8A-8F as BSR-Type), whose value may indicate whether or not MCURLLC data is available to report. In some embodiments, the BSR-in-Data PDU Control Element may be disposed in the first portion of the first octet of the BSR-in-Data PDU, followed by one or more 5 bit BSR-in-Data PDU indexes to represent associated buffer sizes in the same octet or another octet. In some embodiments, the BSR-in-Data PDU Control Element may contain 4 bits, with a first range of values indicating that MC/URLLC data is available to report and the second range of value after the first range indicating that MCURLLC data is not available to report, although the specific ranges shown in Table 3 and position shown in FIGS.8A-8F is merely exemplary. [0071] An example of a BSR-in-Data PDU with a 5-bit BSR Index field is provided in FIG. 8B. In FIG. 8B, the BSR-Type may indicate that

MC/URLLC data is available to report in a first portion of the octet. The second portion of the same octet, along with overflow of the additional bit in the next octet, may indicate the tentative size of the MC/URLLC data in the buffer. The range of data indicated in the BSR Index field may indicate the total amount of MC/URLLC data, which may include the sum. of new, retransmission, user and control MC/URLLC data. In some embodiments of FIGS. 8A-8F, the length of one or more of the fields may be different than those shown.

[0072] Another example of a BSR-in-Data PDU with two 5 -bit BSR

Index fields is provided in FIG. 8C. In FIG. 8C, the first BSR Index field indicates the tentative size of the MC/URLLC data in the buffer. The BSR-Type may indicate a different value than that of FIG. 8B but still indicate that MC/URLLC data is available to report. The BSR-Type and first BSR Index field may be disposed as above. The second BSR Index field may be wholly disposed in the second octet. The first BSR Index field may indicate the tentative total amount of MC URLLC data, similar to that of FIG . 8B. The second BS Index field may indicate the tentative total amount of non-MC/non- URLLC data in the buffer. Similar to the above, the range of data indicated in the second BSR Index field may indicate the total amount of non-MC/non- URLLC data, which may include the sum of new?, retransmission, user and control non-MC/non-URLLC data. As shown, a common index may be used for both the first and second BSR Index fields to transmit the range of buffer sizes for each type of data. In other embodiments, the indexes may be different for different types of data and thus different fields.

[0073] Another example of a BSR-in-Data PDU with three 5-bit BSR

Index fields is provided in FIG. 8D. The BSR-Type may indicate a different value than that of FIGS. 8B and 8C but still indicate that MC URLLC data is available to report. In FIG. 8D, the first BSR Index field indicates the tentative size of the MC/URLLC data in the buffer. The BSR-Type and first and second BSR Index fields may be disposed as above. The third BSR Index field may be disposed in the second and third octets of the BSR-in-Data PDU. The first BSR Index field may indicate the tentative total amount of MC/URLLC data, similar to that of FIG. 8B. The second BSR Index field may indicate the tentative total amount of non-MC/non-URLLC user plane data in the buffer. The third BSR Index field may indicate the tentative total amount of non-MC/non-URLLC control plane data in buffer.

[00741 Another example of a BSR-in-Data PDU with one 5-bit BSR

Index field is provided in FIG. 8E. The BSR-Type may indicate a different value than that of FIGS . 8B-8D. In FIG. 8E, the BSR Type may indicate that no MC/URLLC data is in the buffer. The BSR Index field may indicate the tentati ve total amount of non-MC/non-URLLC data in the buffer. The BSR Index field may be disposed in similar to the arrangement of FIG. 8B, although with an indication of non-MC/non-URLLC data in the buffer rather than MC/URLLC data in the buffer.

[0075J Another example of a BSR-in-Data PDU with two 5-bit BSR

Index fields is provided in FIG. 8F. The BSR-Type may indicate a different value than that of FIGS . 8B-8E. In FIG. 8F, the BSR Type may indicate that no MC/URLLC data is in the buffer. The BSR-Type and first BSR Index field may be disposed in the first octet with an overlap in the second octet, while the second BSR Index field may be wholly disposed in the second octet. The first BSR Index field may indicate the tentative total amount of non-MC/non-URLLC user plane data in the buffer. The second BSR Index field may indicate the tentative total amount of non-MC/non-URLLC control plane data in buffer. Similar to the above, when multiple BSR Index fields are present, the position of the BSR Index fields may be different from above. For example, in FIG. 8F, the BSR Index field indicating the non-MC/non-URLLC control plane data may precede the BSR Index field indicating the non-MC/non-URLLC control plane data.

[0076J Reporting of the BSR by the tUE may be controlled by the tSL-

RRC at the nUE. In particular, the nUE may configure various timers and parameters in the tUE when the tUE associates with the nUE or through control signaling thereafter. Specifically, the timers and parameters can be transmitted from the nUE to the tUE during an initial network access process of the tUE with the nUE or when the nUE transmits a tSL-RRC message to the tUE when tUE is in a connected/active state. The timers that are configured may include a pe odicBSR-Timer, retxBSR-Timer-non-MC-non- URLLC, relxBSR-Timer-MC- URLLC, prohibit-BSR-in-ACK-Timer, prohibit-BSR-in-Data PDU-Timer, and sr-ProhibitTimer. The configuration parameters may include a New- Retransmission-Data-Report-Separately-Enabled, and UP -CP -Data-Report- Separately-Enabled parameter.

[0077J The BSR message transmission from the tUE to the nUE may be either periodically transmitted or transmission may be triggered by an event. One type of event may be the arrival of a new type of data at the tUE. Once transmission of the BSR is triggered, the tUE may transmit a request to the nUE for UL resource allocation. The BSR transmission may be selected from among 3 types: Regular, Periodic or Opportunistic. The type of BSR may be based on the trigger event.

[0078 J Different types of regular BSR transmissions may occur, which may be triggered by different events. The trigger for a regular-BSR transmission may occur when UL data becomes available for transmission in the tSL-HL entity after no data is initially available for transmission in the UL buffers of the tUE. In particular, a Regular-BSR-MC/URLLC transmission may be triggered if any part of the data available for transmission is MC/URLLC data, while a Regular-BSR-non-MC-non-URLLC transmission may be triggered if any part of the data available for transmission is non-MC/non-URLLC. In other embodiments, a Regular-BSR-MC URLLC transmission may be triggered when non-MC/non-URLLC data is available for transmission in the UL buffers and MC/URLLC data becomes available for transmission in the tSL-HL entity. A Regular-BSR-non-MC-non-URLLC transmission may be triggered when the retxBSR-Timer-non-MC-non-URLLC expires and the tSL-HL entity has non- MC/non-URLLC Data available for transmission. Similarly, a Regular-BSR- MC-URLLC transmission may be triggered when the retxBSR-Timer-MC- URLLC expires and the tSL-HL entity has MC/URLLC Data available for transmission.

[0079] A periodic-BSR transmission may be triggered by a different event from those triggering the regular-BSR transmission. In particular, the periodic-BSR transmission may be triggered when the periodicBSR-Timer expires and the tSL-HL entity has MC/URLLC and/or non-MC/non-URLLC data available for transmission.

[0080] Similarly, an opportunistic-BSR transmission may be triggered by a different event from those above. In particular, the opportunistic-BSR transmission may be triggered by an ACK transmission. In particular, the opportunistic-BSR transmission may be triggered when either or both

MC/URLLC or non-MC/non-URLLC data is available for transmission in the UL buffers and an ACK is to be sent for DL HARQ in a subframe. Once the opportunistic-BSR transmission is triggered, the type of transmission may depend on the data, in the UL buffers. If the available data is MC/URLLC, the Opportunistic-BSR-MC-URI_^LC transmission may be triggered to include/embed the opportunistic BSR in the ACK message. The Opportunistic-BSR-MC- UKLLC transmission may be triggered in this case irrespective of whether or not the prohibit-BSR-in-ACK-Timer is running. If the available data is non-MC/non- URLLC and the prohibit-BSR-in-ACK-Timer is not running, the Opportunistic- BSR-non-MC-non-URLLC transmission may be triggered to include/embed the opportunistic BSR in the ACK message. In other cases, such as when the prohibit-BSR-in-ACK-Timer is running and the available data is non-MC/non- URLLC then the Opportunistic-BSR transmission may not be triggered.

[0081 J If the BSR procedure determines that at least one BSR has been triggered and has not been cancelled, the BSR transmission may occur. The transmission may occur at a UL or DL TTI. Once the tSL-HL entity has UL resources allocated for a new transmission in an UL TTI, at the UL TTI the tUE may generate a BSR-in-Data PDU control element, start (or restart) the periodicBSR-Timer , start/restart the retxBSR-Timer-MC-URLLC if the generated BSR-in-Data PDU has a MC/URLLC-related 'BSR-in-Data PDU Index field' and start/restart the retxBSR-Timer-non-MC-non-URLLC if the generated BSR- in-Data PDU has a non-MC/non-URLLC-related 'BSR-in-Data PDU Index field'. Once the tSL-HL entity has UL resources allocated for an ACK transmission for a DL HARQ process in a DL TTI, at the DL TTI the tUE may generate a BSR-in-ACK control element with a shorter (4-bit) BSR Index, start/restart the retxBSR-Timer-MC-URLLC if the generated BSR-in-ACK is associated with MC/URLLC data and start/restart the retxBSR-Timer-non-MC- non-URLLC and start/restart the prohibit-BSR-in-ACK-Timer if the generated BSR-in-ACK is associated with regular data.

[0082] Other situations may occur that are not covered by the above. For example, the tSL-HL entity may not have UL resources allocated for a new transmission for an UL TTI or the tSL-HL entity may not have UL resources allocated for ACK transmission for DL HARQ process in a DL TTI. In such circumstances, if a regular BSR has been triggered for a Regular-BSR- MC/URLLC transmission, a Scheduling Re uest of type SR-MC-URLLC may be triggered. Alternatively, if a regular BSR has been triggered for a Regular-BSR- non-MC-non-URLLC transmission transmission, a Scheduling Request of type SR-non-MC-non-URI C may be triggered.

[0083] Control of a Scheduling Request (SR) transmission may be effected by the tSL-RRC of the tUE. The SR may be used for requesting UL resources for transmission. In particular, the tSL-RRC may control SR transmission by configuring a prohibit timer referred to herein as the sr- ProhibiiTimer. The sr-ProhibitTimer may limit the frequency of SR

transmissions. When an SR is triggered by the tSL-RRC, the SR may be pending until cancelled by the tSL-RRC.

[0084] SRs may be of different types: SR-MC-URLLC or SK-non-MC- non-URLLC. All pending SRs of type SR-MC-URLLC may be cancelled when a PDU includes a BSR that contains a buffer status for MC/URLLC data up to (and including) the last event that triggered a BSR. In addition, pending SRs of type SR-MC-URLLC may be cancelled when the UL grants can accommodate all pending MC/URLLC data available for transmission. Similarly, ail pending SRs of type S?-non-MC -non-URLLC may be cancelled and the sr-ProhibitTimer stopped when a PDU includes a BSR that contains buffer status for non- MC/non-URLLC data up to (and including) the last event that triggered a BSR. In addition, pending SRs of type .SR-non-MC-non-URLLC may be cancelled and the sr-ProhibitTimer stopped when the UL grant(s) can accommodate all pending non-MC/non-URLLC data available for transmission.

[0085] As long as at least one SR is pending, the tSL-HL entity may perform, several functions for each TTI. In some embodiments, if a SR of type 'SR-MC-URLLC is pending and no UL resources are available for a transmission in a TTI, the tUE may initiate a Random Access procedure in the same or very first UL subframe/TTL The tUE may then generate a BSR-in-Data PDU, include the generated BSR-in-Data PDU in the random access message, and cancel all pending SRs. The tUE may subsequently start the sr- ProhibitTimer timer. If, on the other hand, the SR of type '<SK-non-MC-non- URLLC is pending and no UL resources are available for a transmission in a TTI, the tUE may again initiate a Random Access procedure as above so long as the timer sr-ProhibitTimer is not running. In this case, the tUE may then generate a BSR-in-Data PDU, include the generated BSR-in-Data PDU in the random access message, and cancel all pending SRs of the type '.SR-non-MC- non-U LLC'. The tUE may again subsequently start the sr-ProhibitTimer timer.

[0086J A tSL-HL PDU may contain at most one BSR control element, even when multiple events trigger a BSR by the time a BSR can be transmitted . If a tSL-HL PDU has multiple UL grants in a TTI, the BSR may be included in a single PDU. While reporting buffer size, the BSR may reflect data remaining in the buffer after generation of all PDUs for the current TTI.

[008η The tSL-RRC may control the BSR-in-Data PDU format to be transmitted by defining a prohibit timer called prohibit-BSR-in-Data PDU-Timer and configuration parameters such as New-Retransmission-Data-Report- Separately-Enabled, and UP-CP-Data-Report-Separately-Enabled. The tUE may perform several operations to generate and transmit a BSR-in-Data PDU, which, as above may differ dependent on the type of data available for transmission and whether or not the prohibit-BSR-in-Data PDU-Timer is running. The different types of BSR-in-Data PDU described are shown in Table 3 and corresponding FIGS. 8A-8F.

[0088 J In some embodiments, if there is only MC/URLLC data available for transmission, a BSR-in-Data PDU with BSR-Type = 0000 may be generated as described above. Similarly, if there is only non-MC/non-URLLC data available for transmission and prohibit-BSR-in-Data PDU-Timer is not running, a BSR-in-Data PDU may be generated dependent on the value of the UP-CP- Data-Report-Separately-Enabled and New -Retransmission-Data-Report- Separately-Enabled parameters . If the UP-CP-Data-Repori-Separately-Enabled parameter = False (say 0) and the New-Retransmission-Data-Report-Separately- Enabled parameter = False (say 0), a BSR-in-Data PDU of BSR-Type = 1000 may be generated. If the UP-CP-Data-Report-Separately-Enahled parameter = True (say 1) and the New-Retransmission-Data-Report-Separately-Enabled parameter = False (say 0), a BSR-in-Data PDU of BSR-Type - 1001 may be generated. If the UP-CP-Data-Report-Separately-Enabled parameter = False (say 0) and the New-Retransmission-Data-Report-Separately-Enabled parameter = True (say 1), a BSR-in-Data PDU of BSR-Type = 1010 may be generated. If the UP-CP-Data-Report-Separately-Enabled parameter = True (say 1) and the New-Retransmission-Data-Report-Separately-Enabled parameter = True (say 1), a BSR-in-Data PDU of BSR-Type = 101 1 may be generated.

[00891 If both MC/URLLC and non-MC/non-URLLC data is available for transmission and the prohibit-BSR-in-Data PDU -Timer is running, a BSR-in- Data PDU with BSR-Type = 0000 may be generated. However, if both

MC/URLLC and non-MC/non-URLLC data is available for transmission and the prohibit-BSR-in-Data PDU-Timer is not running, a BSR-in-Data PDU may be gen erated that is as above dependent on the value of the UP -CP-Data-Report- Separately-Enabled and New-Retransmission-Data-Report-Separately-Enabled parameters. Similar to the above, if the UP-CP-Data-Repori-Separately- Enabled parameter = False (say 0) and the New-Retransmtsswn-Data-Report- Separately-Enabled parameter = False (say 0), a BSR-in-Data PD of BSR- Type = 0001 may be generated. If the UP -C -Data-Report-Separately-Enabled parameter = True (say 1 ) and the New-Relransmission-Data-Report-Separately- Enabled parameter = False (say 0), a BSR-in-Data PDU of BSR-Type = 0010 may be generated. If the UP-CP-Data-Report-Separately-Enabled parameter = False (say 0) and the New-Retransmission-Data-Report-Separately-Enabled parameter True (say 1), a BSR-in-Data PDU of BSR-Type ^:=: 0011 may be generated. If the UP-CP-Data-Report-Separately-Enabled parameter = True (say 1) and the New-Retransmission-Data-Report-Separately-Enabled parameter =^;: True (say 1), a BSR-in-Data PDU of BSR-Type ^:= 0100 may be generated.

[0090] As well as controlling the BSR-in-Data PDU format, the tSL-

RRC may control the BSR-in-ACK transmission by defining a prohibit timer called ⁱprohibii-BSR-in-ACK-Timer The tUE may perform several operations to generate and transmit a BSR-in-ACK, which, as above may differ dependent on the type of data available for transmission and whether or not the prohibit- BSR-in-ACK-Timer is running. If there is MC/URLLC data available for transmission, an BSR-in-ACK (with BSR-in-ACK index = 0000) may be generated. If there is non-MC/non-URLLC data available for transmission and "prohibit-BSR-in-ACK-Time is not running, an BSR-in-ACK (with BSR-in- ACK index = 0001 to 1110) may be otherwise generated.

[0091] Triggers may also be cancelled by the tUE. In some

embodiments, all triggered BSRs may be cancelled when the UL grant(s) in a current subframe can accommodate all pending data available for transmission. A3] triggered MC URLLC BSRs may be cancelled when a BSR is included in a tSL-HL PDU that carries a buffer size for MC/URLLC data and all triggered non-MC/non-URLLC BSRs may be cancelled when a BSR is included in a tSL- 5 11. PDU that carries a buffer size for non-MC/non-URLLC data. A

Regular/periodic BSR may not be cancelled by transmission of a BSR-in-ACK in a DL HARQ ACK. The tSL-HL entity may transmit at most a single

Regular Periodic/opportunistic BSR in a ΤΉ. All BSRs transmitted in a ΤΤΪ may always reflect the buffer status after all tSL-HL PDUs have been built for the TTI.

[0092 J FIGS. 9A and 9B illustrate downlink and uplink subframe structures in accordance with some embodiments. The DL and UL subframe structures 910, 930 may be used by any of the nUEs or tUEs shown in FIGS. 1 - 5. Each DL and UL subframe 910, 930 may be 1ms, although other

numerologies such as subframe lengths of 0.25ms, 0.5ms, or 2ms can also be supported. Each DL and UL subframe 9 ! 0, 930 may be divided into multiple physical resource blocks (PRB) in the frequency domain in which each PRE may occupy 3 subcarriers over one subframe. For a subcarrier spacing of 90 kHz and subframe duration of 1ms, each PRB may occupy 180 kHz over 1 ms. The PRBs may be grouped into subchannels in which each subchannel occupies 6 PRBs consecutive in the frequency domain. The minimum system bandwidth is of the size of a subchannel. The channels may be transmitted on a PRA, which may be an aggregation of multiple continuous PRBs. [0093] Each DL and UL subfrarne 910, 930 may be divided into a number of sections, each of which is addressed to the same tUE. The first symbol in the subframe 910, 930 may be a common control channel 912 and may indicate whether the data channel 922 is an UL or DL data, channel . Thus, the common control channel 912 may be a DL common control channei independent of whether the data channei 922 in the subframe 910, 930 is UL or DL. The common control channel 912 may have a 10 bit payload in which the UL/DL indication is a single bit.

[0094] The DL common control channei 912 may be followed by a Transmitter resource Acquisition and Sounding (TAS) channel 6. The TAS channel 916 may be a DL channel in the DL subframe 910 and an UL channel in the UL subframe 930. The TAS channel 916 may be used by the transmitter to transmit a reference signal for measurement by the receiver. For example, in the DL subframe 910, the nUE may transmit the reference signal and the tUE may measure the reference signal. The TAS channel 916 may have a 9 bit payload in which the new data indicator (NDI) is a single bit with a 2 bit repetition and 3 bit CRC.

[Θ095] A Receiver resource Acknowledgement and Sounding (RAS) channel 918 may be provided subsequent to the TAS channel 916. The receiver, e.g., the tUE in the RAS channel 918 in the DL subframe 910, may transmit the measurement to the transmitter (nUE in the DL subframe 910). The RAS channel 918 may provide a CSI and power head room (PUR) report. The RAS channel 918 may have a 10 bit payload in which the modulation and coding scheme (MCS) is 4 bits with a 2 bit PHR and 4 bit CRC.

[0096] Tlie TA S and RAS channels 916, 918 may be followed by a DL data channel 922 in a DL subframe 910, or UL data channel in an UL subframe 930. The data channel 922 may contain data provided from the transmitter to the receiver. This data may include ID and security information or user data.

[0097] The data channel 922 may be followed by an ACK/NACK channel 924. The ACK/NACK channel 924 may contain a response to transmission of the data in the data channel 922 and be used by tlie transmitter to determine whether retransmission of the data in the data channel 922 is to occur. The ACK NACK channel 924 may have a 10 bit payload in which the AC NACK is 2 bits with a 4 bit buffer status report (BSR) in a DL subframe 910 indicating whether data is present for transmission and 4 bit CRC.

[0098] The various sections above may be separated by guard periods

914. The guard periods 914 may be used to reduce inter-symbol interference or permit the tUE to switch between the transmitter and receiver chains. At least some of the guard periods 914 may have different lengths. For example, the guard periods between the DL common control channel 12 and the TAS channel 916, between the TAS channel 916 and the RAS channel 918 and after the ACK/NACK channel 924 may occupy 1 symbol (17.7μ8 total), the guard period 914 between the RAS channel 918 and the data channel 922 may occupy 1 symbol + 8.33₍us (26.03μ8 total) and the guard period 914 between the data channel 922 and the ACK/NACK channel 924 may occupy 2 symbols.

[0099] A majority of the subchannels in the system may be used to provide data between UEs. However, one or more of the subchannels may be reserved for control signaling. For example, 1-2 resource elements (REs) of one of the central 6 PRBs in the first DL subframe of each frame may provide broadcast channel information, as well as paging and discovery information. 1 RE may be defined as 1 subcarrier over 1 symbol, 1 resource unit (RU) may be defined as 3 subcarriers over 4 consecutive symbols (in total 12 REs). In some embodiments, the DL common control channel, the TAS channel, the RAS channel and the ACK channel may each occupy one RU, while the data channel may occupy the 3 subcarriers over 34 symbols. The total subframe in this embodiment may thus extend over 56 symbols (including the above guard periods).

[00100] Examples

[00101] Example 1 is an apparatus of user equipment (UE), the apparatus comprising: a memory; and processing circuitry in communication with the memory and arranged to: determine an amount of data of different data types buffered in the memory for transmission to a scheduler UE: send, for transmission to the scheduler UE, a buffer status report (BSR) comprising a BSR control element (CE) that indicates the amount of data of at least one of the different data types, the BSR transmitted in one of a hybrid automatic repeat request (HARQ) transmission to the scheduler UE (BSR-in-ACK) or one of a packet data unit (PDU) or random access message (BSR-in-PDU), the BSR-in- ACK and BSR-in-PDU comprising different amounts of BSR data: and in response to transmission of the BSR, receive an allocation from the scheduler UE for transmission of the data to the scheduler UE.

[00102] In Example 2, the subject matter of Example 1 optionally includes, wherein: the data types comprise new and retransmission control plane (CP) and user plane (UP) ultra-high reliability and low latency communication (URLLC) and non-URLLC UL data, the retransmission data retransmitted at a higher layer protocol stack PDU level for ARQ retransmission.

[00103] In Example 3, the subject matter of any one or more of Examples

1-2 optionally include, wherein the processing circuitry is further configured to: send the BSR-in-ACK in an acknowledgment/negative acknowledgment (ACK/NACK) message in an ACK channel of a downlink subframe, the BSR- in-ACK comprises a BSR-in-ACK CE, the BSR-in-ACK CE comprising an index that indicates a presence of ultra-high reliability and low latency communication (URLLC) data free from an indication of a buffer size of the URLLC data or an indication of a buffer size of an amount of non-URLLC data of different types.

[00104] In Example 4, the subject matter of any one or more of Examples 1-3 optionally include, wherein: the BSR-in-ACK comprises a BSR-in-ACK CE, the BSR-in-ACK CE comprises a BSR type index that indicates a presence of a BSR-in-PDU field and the data in the memory, the BSR-in-PDU field comprising an index of a buffer size of the data.

[00105] In Example 5, the subject matter of Example 4 optionally includes, wherein: the data types comprise new and retransmission control plane (CP) and user plane (UP) ultra-high reliability and low latency communication (URLLC) and non-URLLC data.

[00106] In Example 6, the subject matter of Example 5 optionally includes, wherein: the BSR type index indicates a single field and whether the memory contains URLLC data, and the single field comprises an amount of URLLC data when the BSR type index indicates that the memory contains URLLC data and an amount of non-URLLC data when the BSR type index indicates that the memory is free from URLLC data. [00107] In Example 7, the subject matter of any one or more of Examples 5-6 optionally include, wherein: the B SR. type index indicates multiple fields and whether the memory contains URLLC data, and the fields comprise at least one of: an amount of URLLC data and an amount of non-URLLC data in different fields, an amount of UP non-URLLC data and an amount of CP non- URLLC data in different fields, an amount of ne non-URLLC data and an amount of retransmission non-URLLC data in different fields, or an amount of UP new non-URLLC data, an amount of UP retransmission non-URLLC data, an amount of CP new non-URLLC data and an amount of CP retransmission non-URLLC data in different fields.

[00108] In Example 8, the subject matter of any one or more of Examples

4-7 optionally include, wherein: the BSR type index indicates a number of fields, and each field comprises an index value that indicates an amount of the data type stored in the memory as indicated in the BSR type index and in which a granularity of index values of the field decreases as the amount of the data type increases, a smallest of the granularity based on resource allocation granularity and a number of bits each allocated physical resource block (PRB) carries.

[00109] In Example 9, the subject matter of any one or more of Examples

1-8 optionally include, wherein the processing circuitry is further configured to: decode BSR timers and BSR configuration parameters provided in a Radio Resource Control (RRC) message, the timers and configuration parameters configured to control transmission of the BSR from the UE, determine that a BSR trigger has occurred, and in response to a determination that the BSR trigger has occurred, send, for transmission to the scheduler UE, a request for an uplink (UL) resource allocation .

[00110] In Example 10, the subject matter of Example 9 optionally includes, wherein: the BSR timers comprise a periodic timer that controls periodic BSR transmissions, an ultra-high reliability and low latency communication (URLLC) retransmission timer, a non-URLLC retransmission timer, a BSR-in-ACK timer that prohibits a BSR-in-ACK transmission during operation, a BSR-in-PDU timer that prohibits a BSR-in-PDU transmission during operation, and a Scheduling Request (SR) prohibit timer that prohibits a SR transmission during operation. [00111] In Example 1 1 , the subject matter of Example 10 optionally includes, wherein: a BSR type of the BSR is dependent on the BSR trigger, the BSR type comprising a regular BSR for URLLC data, a regular BSR for non- URLLC data, a periodic BSR, an opportunistic BSR for URLLC data and an opportunistic BSR for non-URLLC data, and the processing circuitry is further configured to at least one of: when the memory is empty of the data, trigger the regular BSR for URLLC data in response to URLLC data being stored in memory and trigger the regular BSR for non-URLLC data in response to non- URLLC data being stored in memory, when the memory contains non-URLLC data, trigger the regular BSR for URLLC data in response to URLLC data being stored in memory, trigger the regular BSR for non-URLLC data when non- URLLC data is stored in the memory and the non-URLLC retransmission timer expires, trigger the regular BSR for URLLC data when URLLC data is stored in the memory and the URLLC retransmission timer expires, trigger the periodic BSR when the periodic timer expires and at least one of URLLC or non-URLLC data is stored in the memory, trigger the opportunistic BSR for URLLC data when a HARQ is to be transmitted by the UE and URLLC data is stored in the memory, irrespective of whether the BSR-in-ACK timer is in operation, and send, for transmission to the scheduler UE, the BSR-in-ACK and trigger the opportunistic BSR for non-URLLC data when the BSR-in-ACK timer expires, a HARQ is to be transmitted by the UE and non-URLLC data is stored in the memory, and send, for transmission to the scheduler UE, the BSR-in-ACK.

[00112] In Example 12, the subject matter of any one or more of

Examples 10-1 1 optionally include, wherein the processing circuitry is further configured to: in an uplink (UL) transmission time index (ΤΉ) in which UL resources are allocated for a data transmission of the UE, after generation of a BSR-in-PDU CE, start or restart the periodic timer, start or restart the URLLC retransmission timer when the BSR-in-PDU indicates that URLLC data is stored in the memory, and start or restart the non-URLLC retransmission timer when the BSR-in-PDLT indicates that non-URLLC data is stored in the memory, and in a downlink (DL) TT1 in which UL resources are allocated for a HARQ transmission of the UE, after generation of a BSR-in-ACK, start or restart the URLLC retransmission timer when the BSR-in-ACK indicates that URLLC data is stored in the memory, and start or restart the non-URLLC retransmission timer and the BSR-in-ACK timer when the BSR-in-ACK indicates that non-URLLC data is stored in the memory, and in a ΤΪΊ free from resources allocated for the UE, send for transmission to the scheduler UE, a regular SR for URLLC data when a regular BSR for URLLC data has been triggered, and a regular SR for non-URLLC data when a regular BSR for non-URLLC data has been triggered.

[00113] In Example 13, the subject matter of any one or more of

Examples 10-12 optionally include, wherein the processing circuitry is further configured to: cancel a URLLC SR in response to transmission of a BSR-in- PDU that contains a last event that triggered transmission of the BSR or a corresponding uplink (UL) grant accommodates pending URLLC data stored in the memory, and cancel a non-URLLC SR in response to transmission of a BSR- in-PDU that contains a last event that triggered transmission of the BSR or a corresponding UL grant accommodates pending non-URLLC data stored in the memory, when a URLLC SR is pending and no UL resources are available for a transmission in a current transmission time index (TTI), initiate a random access procedure in a first available UL subframe, generate a BSR-in-PDU and include the BSR-in-PDU generated in a random access message of the random access procedure, cancel pending SRs, and start the SR prohibit timer, and when a non- URLLC SR is pending, the SR prohibit timer is not running, and no UL resources are available for a transmission in the current ΤΠ, initiate a random access procedure in the first available UL subframe, generate the BSR-in-PDU and include the BSR-in-PDLT generated in the random access message of the random access procedure, cancel pending non-URLLC SRs, and start the SR prohibit timer.

[00114] In Example 14, the subject matter of any one or more of

Examples 10- 13 optionally include, wherein the processing circuitry is further configured to: cancel a BSR trigger when an uplink (UL) grant is able to accommodate pending data, available for transmission, cancel a URLLC BSR trigger when a BSR-in-PDU is transmitted that carries a buffer size of the

URLLC data in the memory, cancel a non-URLLC BSR trigger when a BSR-in- PDU is transmitted that carries a buffer size of the non-URLLC data in the memory, refrain from cancellation of a regular or periodic BSR trigger after transmission of a BSR-in-ACK.

[00115] In Example 15, the subject matter of any one or more of

Examples 9-14 optionally include, wherein: the BSR configuration parameters comprise a first parameter that indicates whether an amount of new and retransmission BSR data is to be transmitted in a first field of the BSR CE in a BSR-in-PDU and a second parameter that indicates whether an amount of CP and UP BSR data is to be transmitted in a second field of the BSR CE in the BSR-in-PDU.

[00116] In Example 16, the subject matter of any one or more of

Examples 1-15 optionally include, wherein: the processing circuitry comprises a baseband processor, and the apparatus further comprises a transceiver configured to communicate with the other UE.

[00117] Example 17 is an apparatus of user equipment (U E), the apparatus comprising: a memory; and processing circuitry in communication with the memory and arranged to: establish uplink (UL) and downlink (DL) communication with another UE in a personal area network (PAN) comprising the UE and the other UE; decode a buffer status report (BSR) from the other UE, the BSR configured to indicate an amount of data buffered in the other UE for UL transmission to the UE, the BSR received one of in a hybrid automatic repeat request (HARQ) transmission to the UE (BSR-in-ACK) or in one of a packet data unit (PDU) or random access message (BSR-in-PDU), the amount of data, comprising at least one of: an amount of ultra-high reliability and low latency communication (URLLC) data, an amount of non-URLLC UL data, an amount of user plane (UP) non-URLLC data and an amount of control plane (CP) non- URLLC data, an amount of new non-URLLC data and an amount of retransmission non-URLLC data, or an amount of UP new non-URLLC data, an amount of UP retransmission non-URLLC data, an amount of CP new non- URLLC data, and an amount of CP retransmission non-URLLC data; and in response to reception of the BSR, send, for transmission to the other UE, an allocation for UL transmission of the data to the UE.

[00118] In Example 18, the subject matter of Example 17 optionally includes, wherein: the BSR-in-ACK comprises a BSR-in-ACK CE that comprises an index thai indicates either: a presence of URLLC data free from an indication of a buffer size of the URLLC data or a range in which the amount of non-URLLC data falls.

[00119] In Example 19, the subject matter of any one or more of

Examples 17- 18 optionally include, wherein: the BSR-in-ACK comprises a BSR-in-ACK CE that comprises a BSR type index that indicates a number of BSR-in-PDU fields and what type of BSR data is in each BSR-in-PDU field, each BSR-in-PDU field comprising an index that indicates a range in which the amount of BSR data in the BSR-in-PDU field fails.

[00120] In Example 20, the subject matter of Example 19 optionally includes, wherein: the BSR type index indicates a single field and whether the other UE has URLLC data buffered, and the single field comprises a range in which the amount of URLLC data falls when the BSR type index indicates that the other UE has URLLC data buffered and a range in which the amount of non- URLLC data, falls when the BSR type index indicates that the other UE is free from having URLLC data buffered.

[00121] In Example 21, the subject matter of Example 20 optionally includes, wherein: the BSR type index indicates multiple fields and whether the memory contains URLLC data, and the fields comprise at least one of: a range in which the amount of URLLC data falls and a range in which the amount of non- URLLC data falls in different fields, a range in which the amount of non- URLLC UP data falls and a range in which the amount of non-URLLC CP data fails in different fields, a range in which the amount of non-URLLC new data fails and a range in which the amount of non-URLLC retransmission data falls in different fields, or a range in which the amount of UP new non-URLLC data falls, a range in which the amount of UP retransmission non-URLLC data falls, a range in which the amount of CP new non-URLLC data fails and a range in which the amount of CP retransmission non-URLLC data falls in different fields.

[00122] In Example 22, the subject matter of any one or more of

Examples 20-21 optionally include, wherein: the BSR type index indicates a number of fields, and each field comprises an index value that indicates a range in which the amount of a data type buffered by the other UE is indicated in the BSR type index and in which a granularity of index values of the field decreases as the amount of the data type increases, a smallest of the granularity based on resource allocation granularity and a number of bits carried by each physical resource block (PRB) allocated by the UE,

[00123] In Example 23, the subject matter of any one or more of

Examples 17-22 optionally include, wherein the processing circuitry is further configured to: send, for transmission to the other UE, a Radio Resource Control (RRC) message comprising BSR timers and BSR configuration parameters, the timers and configuration parameters configured to control transmission of the BSR from the other UE when a BSR trigger indicated by one of the BSR timers and BSR configuration parameters occurs, and the BSR timers comprise a periodic timer that controls periodic BSR transmissions, an URLLC

retransmission timer, a non-URLLC retransmission timer, a BSR-in-ACK timer that prohibits a BSR-in-ACK transmission during operation, a BSR-m-PDU timer that prohibits a BSR-in-PDU transmission during operation, and a Scheduling Request (SR) prohibit timer that prohibits a SR transmission during operation.

[00124] In Example 24, the subject matter of Example 23 optionally includes, wherein: a BSR type of the BSR is dependent on the BSR trigger, and the BSR type comprises a regular BSR for URLLC data, a regular BSR for non- URLLC data, a periodic BSR, an opportunistic BSR for URLLC data and an opportunistic BSR for non-URLLC data, the regular BSR for URLLC data is configured to be triggered in response to buffering of URLLC data and the regular BSR for non-URLLC data is configured to be triggered in response to buffering of non-URLLC data, the regular BSR for URLLC data is configured to be triggered in response to buffering of URLLC data when non-URLLC data is present, the regular BSR for non-URLLC data is configured to be triggered in response to non-URLLC data being present when the non-URLLC

retransmission timer expires, the regular BSR for URLLC data is configured to be triggered in response to URLLC data being present when the URLLC retransmission timer expires, trigger the periodic BSR is configured to be triggered when the periodic timer expires and at least one of URLLC or non- URLLC data is present, trigger the opportunistic BSR for URLLC data when a HARQ is received by the UE and URLLC data is present, irrespective of whether the BSR-in-ACK timer is in operation, and trigger the opportunistic BSR for non-URLLC data when the BSR-in-ACK timer expires, a HARQ is received by the UE and non-URLLC data is present.

[00125] In Example 25, the subject matter of any one or more of

Examples 23-24 optionally include, wherein: the BSR configuration parameters comprise a first parameter that indicates whether an amount of new and retransmission BSR data is to be transmitted in a first field of the BSR CE in a BSR-in-PDU and a second parameter that indicates whether an amount of CP and UP BSR data is to be transmitted in a second field of the BSR CE in the BSR-in-PDU.

[00126] Example 26 is a computer-readable storage medium that stores instructions for execution by one or more processors of a user equipment (UE), the one or more processors to: determine amounts of buffered uplink (UL) data, the amounts comprising an amount of ultra-high reliability and low latency communication (URLLC) data, an amount of non-URLLC UL data, an amount of user plane (UP) non-URLLC data, an amount of control plane (CP) non- URLLC data, an amount of new non-URLLC data, an amount of retransmission non-URLLC data, an amount of UP new non-URLLC data, an amount of UP retransmission non-URLLC data, an amount of CP new non-URLLC data and an amount of CP retransmission non-URLLC data; and transmit to a scheduler UE that allocates UL resources for the UE, a buffer status report (BSR) that indicates at least one of the amounts of buffered UL data in a BSR control element (CE), the BSR transmitted one of in a hybrid automatic repeat request (HARQ) transmission to the scheduler UE (BSR-in-ACK) or in one of a packet data unit (PDU) or random access message (BSR-in-PDU).

[00127] In Example 27, the subject matter of Example 26 optionally includes, wherein: the BSR-in-ACK comprises a BSR-in-ACK CE that comprises an index that indicates a presence of URLLC data free from an indication of a buffer size of the URLLC data or an indication of the amount of non-URLLC data, and the BSR-in-PDU comprises a BSR-in-PDU CE that comprises a BSR type index that indicates a number of BSR-in-PDU fields and what type of BSR data is in each BSR-in-PDU field, each particular BSR-in~ PDU field comprising an index of the amount of BSR data in the particular BSR- in-PDU field.

[00128] Example 28 is an apparatus of a user equipment (UE), the apparatus comprising: means for detennining amounts of buffered uplink (UL) data, the amounts comprising an amount of ultra-high reliability and low latency communication (URLLC) data, an amount of non-URLLC UL data, an amount of user plane (UP) non-URLLC data, an amount of control plane (CP) non- URLLC data, an amount of new non-URLLC data, an amount of retransmission non-URLLC data, an amount of UP new non-URLLC data, an amount of UP retransmission non-URLLC data, an amount of CP new non-URLLC data and an amount of CP retransmission non-URLLC data; and means for transmitting to a scheduler UE that allocates UL resources for the UE, a buffer status report (BSR) that indicates at least one of the amounts of buffered UL data in a BSR control element (CE), the BSR transmitted one of in a hybrid automatic repeat request (HARQ) transmission to the scheduler UE (BSR-in-ACK) or in one of a packet data unit (PDU) or random access message (BSR-in-PDU).

[00129] In Example 29, the subject matter of Example 28 optionally includes, wherein: the BSR-in-ACK comprises a BSR-in-ACK CE that

comprises an index that indicates a presence of URLLC data free from an indication of a buffer size of the URLLC data or an indication of the amount of non-URLLC data, and the BSR-in-PDU comprises a BSR-in-PDU CE that comprises a BSR type index that indicates a number of BSR-in-PDU fields and what type of BSR data is in each BSR-in-PDU field, each particular BSR-in- PDU field comprising an index of the amount of BSR data in the particular BSR- in-PDU field.

[00130] Example 30 is a method of scheduling uplink (UL) transmissions of a user equipment (UE), the method comprising: determining amounts of buffered UL data, the amounts comprising an amount of ultra-high reliability and low latency communication (URLLC) data, an amount of non-URLLC UL data, an amount of user plane (UP) non-URLLC data, an amount of control plane (CP) non-URLLC data, an amount of new non-URLLC data, an amount of retransmission non -URLLC data, an amount of UP new non-URLLC data, an amount of UP retransmission non-URLLC data, an amount of CP new non- URLLC data and an amount of CP retransmission non-URLLC data; and transmitting to a scheduler UE that allocates UL resources for the UE, a buffer status report (BSR) that indicates at least one of the amounts of buffered UL data in a BSR control element (CE), the BSR transmitted one of in a hybrid automatic repeat request (HARQ) transmission to the scheduler UE (BSR-in-ACK) or in one of a packet data unit (PDU) or random access message (BSR-in-PDU).

[00131] In Example 31 , the subject matter of Example 30 optionally includes, wherein: the BSR-in-ACK comprises a BSR-in-ACK CE that comprises an index that indicates a presence of URLLC data free from an indication of a buffer size of the URLLC data or an indication of the amount of non-URLLC data, and the BSR-in-PDU comprises a BSR-in-PDU CE that comprises a BSR type index that indicates a number of BSR-in-PDU fields and what type of BSR data is in each BSR-in-PDU field, each particular BSR-in- PDU field comprising an index of the amount of BSR data in the particular BSR- in-PDU field,

[00132] Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The

accompanying drawings that form a part hereof show, by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

[00133] The subject matter may be referred to herein, individually and/or collectively, by the term "embodiment" merely for convenience and without intending to voluntarily limit the scope of this application to any single inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and oilier embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

[00134] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of "at least one" or "one or more." In this document, the term "or" is used to refer to a nonexclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated. In this document, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, that is, a system, UE, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

[00135] The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1 .72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim . Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims

CLAIMS What is claimed is:

1. An apparatus of user equipment (UE), the apparatus comprising:

a memory; and

processing circuitry in communication with the memory and arranged to: determine an amount of data of different data types buffered in the memory for transmission to a scheduler UE;

send, for transmission to the scheduler UE, a buffer status report (BSR) comprising a BSR control element (CE) that indicates the amount of data of at least one of the different data types, the BSR transmitted in one of a hybrid automatic repeat request (HARQ) transmission to the scheduler UE (BSR-in-ACK) or one of a packet data unit (PDU) or random access message (BSR-in-PDU), the BSR-in-ACK and BSR-in- PDU comprising different amounts of BSR data; and

in response to transmission of the BSR, receive an allocation from the scheduler UE for transmission of the data to the scheduler UE,

2. The apparatus of claim 1, wherein:

the data types comprise new and retransmission control plane (CP) and user plane (UP) ultra-high reliability and low latency communication (URLLC) and non- LIRLLC UL data, the retransmission data retransmitted at a higher layer protocol stack PDU level for ARQ retransmission.

3. The apparatus of claim 1 or 2, wherein the processing circuitry is further configured to:

send the BSR-in-ACK in an acknowledgment/negative acknowledgment (ACK/NACK) message in an ACK channel of a downlink subfrarne, the BSR- in-ACK comprises a BSR-in-ACK CE, the BSR-in-ACK CE comprising an index that indicates a presence of ultra-high reliability and low latency communication (URLLC) data free from an indication of a buffer size of the URLLC data or an indication of a buffer size of an amount of non-URLLC data of different types.

4. The apparatus of claim 1 or 2, wherein:

the BSR-in-ACK comprises a BSR-m-ACK CE, the BSR-in-ACK CE comprises a BSR type index that indicates a presence of a BSR-in-PDU field and the data in the memory, the BSR-in-PDU field comprising an index of a buffer size of the data.

5. The apparatus of claim 4, wherein:

the data types comprise new and retransmission control plane (CP) and user plane (UP) ultra-high reliability and low latency communication (URLLC) and non-URLLC data,

6. The apparatus of claim 5, wherein:

the BS type index indicates a single field and whether the memory contains URLLC data, and

the single field comprises an amount of URLLC data when the BSR type index indicates that the memory contains URLLC data and an amount of non- URLLC data when the BSR type index indicates that the memory is free from. URLLC data.

7. The apparatus of claim 5, wherein:

the BSR type index indicates multiple fields and whether the memory contains URLLC data, and the fields comprise at least one of:

an amount of URLLC data and an amount of non-URLLC data in different fields,

an amount of UP non-URLLC data and an amount of CP non-URLLC data in different fields,

an amount of new non-URLLC data and an amount of retransmission non-URLLC data in different fields, or

an amount of UP new non-URLLC data, an amount of UP retransmission non-URLLC data, an amount of CP new non-URLLC data and an amount of CP retransmission non-URLLC data in different fields.

8. The apparatus of claim 4, wherein: the BSR type index indicates a number of fields, and

each field comprises an index value that indicates an amount of the data type stored in the memory as indicated in the BSR type index and in which a granularity of index values of the field decreases as the amount of the data type increases, a smallest of the granularity based on resource allocation granularity and a number of bits each allocated physical resource block (PRB) carries.

9. The apparatus of claim 1 or 2, wherein the processing circuitry is further configured to:

decode BSR timers and BSR configuration parameters provided in a

Radio Resource Control (RRC) message, the timers and configuration parameters configured to control transmission of the BSR from the UE,

determine that a BSR trigger has occurred, and

in response to a determination that the BSR trigger has occurred, send, for transmission to the scheduler UE, a request for an uplink (UL) resource allocation.

10. The apparatus of claim 9, wherein;

the BSR timers comprise a periodic timer that controls periodic BSR transmissions, an ultra-high reliability and low latency communication (URLLC) retransmission timer, a non-URLLC retransmission timer, a BSR-in-ACK timer that prohibits a BSR-in-ACK transmission during operation, a BSR-in-PDU timer that prohibits a BSR-in-PDU transmission during operation, and a Scheduling Request (SR) prohibit timer that prohibits a SR transmission during operation.

11. The apparatus of claim 10, wherein:

a BSR type of the BSR is dependent on the BSR trigger, the BSR type comprising a regular BS for URLLC data, a regular BSR for non-URLLC data, a periodic BSR, an opportunistic BSR for URLLC data and an opportunistic BSR for non-URLLC data, and

the processing circuitry is further configured to at least one of: when the memory is empty of the data, trigger the regular BSR for URLLC data in response to URLLC data being stored in memory and trigger the regular BSR for non-URLLC data in response to non-URLLC data bemg stored in memory,

when the memory contains non-URLLC data, trigger the regular BSR for URLLC data in response to URLLC data being stored in memory,

trigger the regular BSR for non-URLLC data when non-URLLC data is stored in the memory and the non-URLLC retransmission timer expires,

trigger the regular BSR for URLLC data when URLLC data is stored in the memory and the URLLC retransmission timer expires, trigger the periodic BSR when the periodic timer expires and at least one of URLLC or non-URLLC data is stored in the memory, trigger the opportunistic BSR for URLLC data when a HARQ is to be transmitted by the UE and URLLC data is stored in the memory, irrespective of whether the BSR-in-ACK time is in operation, and send, for transmission to the scheduler UE, the BSR-in-ACK and

trigger the opportunistic BSR for non-URLLC data when the BSR-in-ACK timer expires, a HARQ is to be transmitted by the UE and non-URLLC data is stored in the memory, and send, for transmission to the scheduler UE, the BSR-in-ACK.

12. The apparatus of claim 10, wherein the processing circuitry is further configured to:

in an uplink (UL) transmission time index (TTI) in which UL resources are allocated for a data transmission of the UE, after generation of a BSR-in- PDU CE, start or restart the periodic timer, start or restart the URLLC retransmission timer when the BSR-in-PDU indicates that URLLC data is stored in the memory, and start or restart the non-URLLC retransmission timer when the BSR-in-PDU indicates that non-URLLC data is stored in the memory, and in a downlink (DL) ΊΤΙ in which UL resources are allocated for a HARQ transmission of the UE, after generation of a BSR-in-ACK, start or restart the URLLC retransmission timer when the BSR-in-ACK indicates that URLLC data is stored in the memor -, and start or restart the non-URLLC retransmission timer and the BSR-in-ACK timer when the BSR-in-ACK indicates that non-URLLC data is stored in the memory, and

in a TTI free from resources allocated for the UE, send for transmission to the scheduler UE, a regular SR for URLLC data when a regular BSR for URLLC data has been triggered, and a regular SR for non-URLLC data when a regular BSR for non-URLLC data has been triggered.

13. The apparatus of claim 10, wherein the processing circuitry is further configured to:

cancel a URLLC SR in response to transmission of a BSR-in-PDU that contains a last event that triggered transmission of the BSR or a corresponding uplink (UL) grant accommodates pending URLLC data stored in the memory, and cancel a non-URLLC SR in response to transmission of a BSR-in-PDU that contains a last event that triggered transmission of the BSR or a corresponding UL grant accommodates pending non-URLLC data stored in the memory,

when a URLLC SR is pending and no UL resources are available for a transmission in a current transmission time index (TTI), initiate a random access procedure in a first available UL subframe, generate a BSR-in-PDU and include the BSR-in-PDU generated in a random access message of the random access procedure, cancel pending SRs, and start the SR prohibit timer, and

when a non-URLLC SR is pending, the SR prohibit timer is not running, and no UL resources are available for a transmission in the current TTI, initiate a random access procedure in the first available UL subframe, generate the BSR- in-PDU and include the BSR-in-PDU generated in the random access message of the random access procedure, cancel pending non-URLLC SRs, and start the SR prohibit timer.

14. The apparatus of claim 10, wherein the processing circuitry is further configured to:

cancel a BSR trigger when an uplink (UL) grant is able to accommodate pending data available for transmission, cancel a URLLC BSR trigger when a BSR-in-PDU is transmitted that carries a buffer size of the URLLC data in the memory,

cancel a non-URLLC BSR trigger when a BSR-in-PDU is transmitted that carries a buffer size of the non-URLLC data in the memory,

refrain from cancellation of a regular or periodic BSR trigger after transmission of a BSR-in-ACK.

15. The apparatus of claim 9, wherein:

the BSR configuration parameters comprise a first parameter that indicates whether an am ount of new and retransmi ssion BSR data is to be transmitted in a first field of the BSR CE in a BSR-in-PDU and a second parameter that indicates whether an amount of CP and UP BSR data is to be transmitted in a second field of the BSR CE in the BSR-in-PDU.

16. The apparatus of claim 1 or 2, wherein;

the processing circuitry comprises a baseband processor, and the apparatus further comprises a transceiver configured to communicate with the other UE.

17. An apparatus of user equipment (UE), the apparatus comprising:

a memory; and

processing circuitry in communication with the memory and arranged to: establish uplink (UL) and downlink (DL) communication with another UE in a personal area network (PAN) comprising the UE and the other UE;

decode a buffer status report (BSR) from the other UE, the BSR configured to indicate an amount of data buffered in the other UE for UL transmission to the UE, the BSR received one of in a hybrid automatic repeat request (HARQ) transmission to the UE (BSR-in-ACK) or in one of a packet data unit (PDU) or random access message (BSR-in-PDU), the amount of data comprising at least one of:

an amoimt of ultra-high reliability and low latency communication (URLLC) data, an amount of non-URLLC UL data,

an amount of user plane (UP) non-URLLC data and an amount of control plane (CP) non-URLLC data, an amount of new non-URLLC data, and an amount of retransmission non-URLLC data, or

an amount of UP new non-URLLC data, an amount of UP retransmission non-URLLC data, an amount of CP new non- URLLC data and an amount of CP retransmission non-URLLC data; and

in response to reception of the BSR, send, for transmission to the other UE, an allocation for UL transmission of the data, to the UE.

18. The apparatus of claim 17, wherein:

the BSR-in-ACK comprises a BSR-in-ACK CE that comprises an index that indicates either;

a presence of URLLC data free from an indication of a buffer size of the U RLLC data or

a range in which the amount of non-URLLC data, falls,

19. The apparatus of claim 17 or 18, wherein:

the BSR-in-ACK comprises a BSR-in-ACK CE that comprises a BSR type index that indicates a number of BSR-in-PDU fields and what type of BSR data is in each BSR-in-PDU field, each BSR-in-PDU field comprising an index that indicates a range in which the amount of BSR data in the BSR-in-PDU field falls.

20. The apparatus of claim 19, wherein:

the BSR type index indicates a single field and whether the other UE has URLLC data, buffered, and

the single field comprises a range in which the amount of URLLC data fails when the BSR type index indicates that the other UE has URLLC data buffered and a range in which the amount of non-URLLC data falls when the BSR type index indicates that the other UE is free from having URLLC data buffered.

21 . The apparatus of claim 20, wherein:

the BSR type index indicates multiple fields and whether the memory contains URLLC data, and the fields comprise at least one of:

a range in which the amount of URLLC data, falls and a range in which the amount of RLLC data falls in different fields,

a range in which the amount of non-URLLC UP data falls and a range in which the amount of non-URLLC CP data falls in different fields,

a range in which the amount of non-URLLC new data falls and a range in which the amount of non-URLLC retransmission data fails in different fields, or

a range in which the amount of UP new non-URLLC data falls, a range in which the amount of UP retransmission non-URLLC data falls, a range in which the amount of CP new non-URLLC data falls and a range in which the amount of CP retransmission non-URLLC data falls in different fields.

22. The apparatus of claim 20, wherein:

the BSR type index indicates a number of fields, and

each field comprises an index value that indicates a range in which the amount of a data type buffered by the other UE is indicated in the BSR type index and in which a granularity of index values of the field decreases as the amount of the data type increases, a smallest of the granularity based on resource allocation granularity and a number of bits carried by each physical resource block (PRB) allocated by the UE.

23. The apparatus of claim 17 or 18, wherein the processing circuitry is further configured to:

send, for transmission to the other UE, a Radio Resource Control ( RRC ) message comprising BSR timers and BSR configuration parameters, the timers and configuration parameters configured to control transmission of the BSR from the oilier UE when a BSR trigger indicated by one of the BSR timers and BSR configuration parameters occurs, and

the BSR timers comprise a periodic timer that controls periodic BSR transmissions, an URLLC retransmission timer, a non-URLLC retransmission timer, a BSR-in-ACK timer that prohibits a BSR-in-ACK transmission during operation, a BSR-in-PDU timer that prohibits a BSR-in-PDU transmission during operation, and a Scheduling Request (SR) prohibit timer that prohibits a SR transmission during operation.

24. The apparatus of claim 23, wherein:

a BSR type of the BSR is dependent on the BSR trigger, and the BSR type comprises a regular BSR for URLLC data, a regular BSR for non-URLLC data, a periodic BSR, an opportunistic BSR for URLLC data, and an

opportunistic BSR for non-URLLC data,

the regular BSR for URLLC data is configured to be triggered in response to buffering of URLLC data and the regular BSR for non-URLLC data is configured to be triggered in response to buffering of non-URLLC data, the regular BSR for URLLC data is configured to be triggered in response to buffering of URLLC data when non-URLLC data is present,

the regular BSR for non-URLLC data is configured to be triggered in response to non-URLLC data being present when the non-URLLC

retransmission timer expires,

the regular BSR for URLLC data is configured to be triggered in response to URLLC data being present when the URLLC retransmission timer expires,

trigger the periodic BSR is configured to be triggered when the periodic timer expires and at least one of URLLC or non-URLLC data is present,

trigger the opportunistic BSR for URLLC data when a HARQ is received by the UE and URLLC data is present, irrespective of whether the BSR-in-ACK timer is in operation, and trigger the opportunistic BSR for non-URLLC data when the BS -in- ACK timer expires, a HARQ is received by the UE and non-URLLC data is present.

25. Hie apparatus of claim 23 , wherein :

the BSR configuration parameters comprise a first parameter that indicates whether an amount of new and retransmission BSR data is to be transmitted in a first field of the BSR CE in a BSR-in-PDU and a second parameter that indicates whether an amount of CP and UP BSR data is to transmitted in a second field of the BSR CE in the BSR-in-PDU.

26. A computer-readable storage medium that stores instructions for execution by one or more processors of a user equipment (UE), the one or more processors to:

determine amounts of buffered uplink (UL) da ta, the amounts comprising an amount of ultra-high reliability and low latency communication (URLLC) data, an amount of non-U RLLC UL data, an amount of user plane (UP) non- URLLC data, an amount of control plane (CP) non-URLLC data, an amount of new non-URLLC data, an amount of retransmission non-URLLC data, an amount of UP new non-URLLC data, an amount of UP retransmission non- URLLC data, an amount of CP new non-URLLC data and an amount of CP retransmission non-URLLC data; and

transmit to a scheduler UE that allocates UL resources for the UE, a buffer status report (BSR) that indicates at least one of the amounts of buffered UL data in a BSR control element (CE), the BSR transmitted one of in a hybrid automatic repeat request (HARQ) transmission to the scheduler UE (BSR-in- ACK) or in one of a packet data unit (PDU) or random access message (BSR-in- PDU).

27. The medium of claim 26, wherein:

the BSR-in-ACK comprises a BSR-in-ACK CE that comprises an index that indicates a presence of URLLC data, free from an indication of a buffer size of the URLLC data or an indication of the amount of non-URLLC data, and the BSR-in-PDU comprises a BSR-in-PDU CE that comprises a BSR type index that indicates a number of BSR-in-PDU fields and what type of BSR data is in each BSR-in-PDU field, each particular BSR-in-PDU field comprising an index of the amount of BSR data in the particular BSR-in-PDU field.