WO2025043633A1 - Techniques to support dynamic grant-less transmissions - Google Patents

Abstract

Embodiments provide resource-efficient techniques to adapt to dynamically varying traffic using projected resource demands. Various embodiments utilize a dynamic grant-less (DGL) transmission scheme that synchronizes UEs and BSs including synchronization of allocated resources with incoming packets using complimentary AI and/or ML models at the UEs and BSs. For example, an ML model at the BS may predict the size and time of upcoming packet arrival using reports from the UE to align with incoming packets at the UE, and then the BS allocates resources using the prediction. Further, a complimentary ML model at the UE may predict the size and time of upcoming packet arrival using historical packet arrival pattern and calculate the allocated resources simultaneously.

Description

TECHNIQUES TO SUPPORT DYNAMIC GRANT-LESS TRANSMISSIONS

FIELD OF DISCLOSURE

This disclosure related generally to wireless technology and more particularly to techniques to support dynamic grant-less (DGL) transmissions.

BACKGROUND

In telecommunications, 5G is the fifth-generation technology standard for broadband cellular networks. Like its predecessors, 5G networks are cellular networks, in which the service area is divided into small geographical areas called network cells (or cells) . The 3rd Generation Partnership Project (3GPP) is the industry consortium that sets standards for 5G. One of the techniques supported by 5G includes low latency communications, such as ultra reliable low latency communications (URLLC) . Generally, URLLC refers to using the network for mission critical applications that require uninterrupted and robust data exchange. For example, mission critical applications may include one or more of public safety, remote diagnosis/surgery, emergency response, autonomous driving, industrial automation, and smart energy/grid. Oftentimes, URLLC requires an availability greater than 99.999%and an end-to-end system delay not exceeding 5 milliseconds. Other uses for low latency communications may include extended reality, cloud gaming, streaming, and haptic communications.

BRIEF SUMMARY

Processes, machines, and articles of manufacture for supporting DGL transmissions in low latency communications are described. It will be appreciated that the embodiments may be combined in any number of ways without departing from the scope of this disclosure.

Embodiments may include monitoring an inter-packet arrival time of data packets at a buffer; determining a projected resource demand for an uplink wireless transmission, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs; identifying arrival, at the buffer, of a data packet corresponding to the projected resource demand; and transmitting the data packet with a buffer status report (BSR) to a base station (BS) according to the projected resource demand, wherein the BSR includes a last inter-packet arrival time.

Embodiments may include receiving, from a user equipment (UE) , a first uplink wireless transmission including an inter-packet arrival time between arrival of a first data packet in a buffer of the UE and arrival of a second data packet in the buffer of the UE; determining, based on the inter-packet arrival time, a projected resource demand for a second uplink wireless transmission including a third data packet, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs; and receiving the second uplink wireless transmission including the third data packet based on the projected resource demand determined for the second uplink wireless transmission including the third data packet.

Other processes, machines, and articles of manufacture are also described hereby, which may be combined in any number of ways, such as with the embodiments of the brief summary, without departing from the scope of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

FIG. 1 illustrates an example wireless communication system according to some embodiments.

FIG. 2 illustrates a base station (BS) in communication with a user equipment (UE) device according to some embodiments.

FIG. 3 illustrates an example block diagram of a UE according to some embodiments.

FIG. 4 illustrates an example block diagram of a BS according to some embodiments.

FIG. 5 illustrates an example block diagram of cellular communication circuitry according to some embodiments.

FIG. 6 illustrates an example block diagram of a network message according to some embodiments.

FIGS. 7A and 7B illustrate exemplary block diagrams of various components for implemented DGL transmissions according to some embodiments.

FIG. 8 illustrates various aspects of dynamic grant-less (DGL) transmissions according to some embodiments.

FIG. 9 illustrates a process diagram for DGL transmissions according to some embodiments.

FIGS. 10A and 10B illustrate various aspects of handling prediction errors according to some embodiments.

FIG. 11 illustrates a process diagram of various aspects of DGL transmissions according to some embodiments.

FIGS. 12A and 12B illustrate various aspects of contention-free provisioning for multi-user DGL transmissions according to some embodiments.

FIG. 13 illustrates various aspects of contention-based provisioning for multi-user DGL transmissions according to some embodiments.

FIG. 14 illustrates various aspects of using network functions to support DGL transmissions according to some embodiments.

FIG. 15 illustrates various aspects of utilizing packet data unit (PDU) sessions for DGL transmissions according to some embodiments.

FIG. 16 illustrates an exemplary flowchart for DGL transmissions according to some embodiments.

FIG. 17 illustrates an exemplary flowchart for DGL transmissions according to some embodiments.

FIG. 18 illustrates a logic flow of an exemplary technique for DGL transmissions at a UE according to some embodiments.

FIG. 19 illustrates a logic flow of an exemplary technique for DGL transmissions at a BS according to some embodiments.

DETAILED DESCRIPTION

Generally, this disclosure describes techniques to support DGL transmissions for low latency communications. More specifically, embodiments are directed to utilizing projected resource demands to perform DGL transmissions, such as by using complimentary artificial intelligence (AI) and/or machine learning (ML) models at the UE and BS. In the following description, numerous specific details are set forth to provide thorough explanation of embodiments of the present disclosure. It will be apparent, however, to one skilled in the art, that embodiments of the present disclosure may be practiced without these specific details. In  other instances, well-known components, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description.

Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment.

In the following description and claims, the terms “coupled” and “connected, ” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” may be used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” may be used to indicate the establishment of communication between two or more elements that are coupled with each other.

The processes depicted in the figures that follow, are performed by processing logic that comprises hardware (e.g., circuitry, dedicated logic, et cetera) , software (such as is run on a general-purpose computer system or a dedicated machine) , or a combination of both. Although the processes are described below in terms of some sequential operations, it should be appreciated that some of the operations described may be performed in different order. Moreover, some operations may be performed in parallel rather than sequentially.

The terms “server, ” “client, ” and “device” are intended to refer generally to data processing systems rather than specifically to a particular form factor for the server, client, and/or device.

Existing techniques for low latency communications fail to provide the ability to adapt to dynamically varying traffic. For example, scheduling of resources is performed in a reactive manner that waits until data packets are in a buffer before requesting resources for transmitting the data packets. Adding further complexity, oftentimes low latency communications applications require uplink communications for varying packet data unit size with possible jitter. Further, the uplink communications may be periodic, quasi-periodic, or nonperiodic. Uplink communications with low latency may be required for applications such as gaming, streaming, autonomous driving, and the like. However, granting uplink resources for such applications with existing techniques (e.g., semi-persistent scheduling, dynamic scheduling for aperiodic data arrival, and configured grants) results in numerous inefficiencies, such as  excessive resource allocation, poor resource utilization, inflated overhead, and excessive latency. For example, existing techniques for configured grant scheduling in 5G has a fixed periodicity and a fixed PRB allocation, which is not suitable for non-periodic traffic because the fixed periodicity and/or the fixed PRB allocation will almost always result in either insufficient PRB allocation or excessive PRB allocation. In another example, existing techniques for dynamic scheduling for aperiodic data arrival in 5G requires regular handshake delays associated with scheduling requests and uplink grant exchange. These limitations can drastically reduce the usability and applicability of telecommunication systems, contributing to poor user experiences and inefficient systems, devices, and techniques with limited capabilities.

Accordingly, many embodiments disclosed hereby provide resource-efficient techniques to adapt to dynamically varying traffic using projected resource demands. Various embodiments utilize a dynamic grant-less (DGL) transmission scheme that synchronizes UEs and BSs including synchronization of allocated resources with incoming packets using complimentary AI and/or ML models at the UEs and BSs. For example, an ML model at the BS may predict the size and time of upcoming packet arrival using reports from the UE to align with incoming packets at the UE, and then the BS allocates resources using the prediction. Further, a complimentary ML model at the UE may predict the size and time of upcoming packet arrival using historical packet arrival pattern and calculate the allocated resources simultaneously. Thus, future packet arrival profiles may be predicted for aperiodic traffic patterns with irregular packet arrival times and varying packet sizes.

In several embodiments, the UE reports the AI/ML model (s) to the BS to predict the size and/or time of upcoming packet arrivals, enabling the BS to assign UL resources without additional requests from the UE. Accordingly, the UE may be provided with resources for aperiodic uplink transmissions without the need for regular control signaling from the BS (e.g., via the physical downlink control channel (PDDCH) ) . The transmissions may be setup via initial configuration exchange and are adjusted using subsequent traffic configuration and/or channel updates (e.g., traffic pattern, channel quality, etc. ) . In some embodiments, the UE is implicitly informed about physical resource block (PRB) allocation of the upcoming packets based on PRB configuration messaging. In many embodiments, UE feedback may include a modified BSR, which may include a legacy BSR plus additional information (e.g., inter-arrival time between previous packet and/or current packet size) . This can allow both the UE and the BS to predict the occurrence and size of the next packet arrival in the UE buffer and for the UE  and BS to both have a common understanding of the resource allocation. The DGL transmission techniques described hereby can work with legacy signaling framework alongside and AI/ML model at the UE and another AI/ML model at the BS. Further, enhanced signaling can be used to provide further inputs to AI/ML models for additional improvements.

In these and other ways, components/techniques described hereby may provide many technical advantages. For instance, the computer-based techniques of the current disclosure improve the functioning of a telecommunications system as compared to conventional approaches because the techniques enable DGL transmissions that can improve accessibility, reduce latency (e.g., scheduling latency) , lower overhead, and provide expanded capabilities for telecommunication systems versus conventional approaches. For example, as compared to 5G dynamic scheduling for aperiodic data arrival, the DGL techniques described hereby can avoid regular handshake delays associated with scheduling requests and UL grant exchange and reduce overall control signaling overhead (e.g., scheduling requests and downlink control information) . In another example, as compared to 5G configured grant transmissions, the DGL techniques described hereby can increase resource utilization, reduce latency through aligning scheduled PRBs with packet arrivals at the UE, reduce media access control (MAC) buffer size requirements, reduce packet drop rate for delay critical applications with latency bounds, and increase reliability while reducing the number of repetition in shared resources in multi-user setup. Accordingly, embodiments disclosed hereby can be practically utilized to improve the functioning of a computer and/or to improve a variety of technical fields including telecommunications, computer networks, scheduling, resource utilization, low latency communications, URLLC, artificial intelligence, machine learning, and/or user experience.

It will be appreciated that various aspects of telecommunication networks, capabilities, protocols, formats, and procedures relevant to the techniques described and terms referenced herein can be found in 3GPP technical specifications (TS) , such as TS 23.502, TS 22.261, TS 38.214, TS 38.300, and TS 38.321.

FIG. 1 illustrates a simplified example wireless communication system, according to some embodiments. It is noted that the system of FIG. 1 is merely one example of a possible system, and that features of this disclosure may be implemented in any of various systems, as desired.

As shown, the example wireless communication system includes a base station 102A which communicates over a transmission medium with one or more user devices 106A, 106B,  et cetera, through 106N. Each of the user devices may be referred to herein as a “user equipment” (UE) or UE device. Thus, the user devices 106 are referred to as UEs or UE devices.

The base station (BS) 102A may be a base transceiver station (BTS) or cell site (a “cellular base station” ) and may include hardware that enables wireless communication with the UEs 106A through 106N.

The communication area (or coverage area) of the base station may be referred to as a “cell. ” The base station 102A and the UEs 106 may be configured to communicate over the transmission medium using any of various radio access technologies (RATs) , also referred to as wireless communication technologies, or telecommunication standards, such as GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces) , LTE, LTE-Advanced (LTE-A) , 5G new radio (5G NR) , HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD) , 6G, et cetera. Note that if the base station 102A is implemented in the context of LTE, it may alternately be referred to as an ‘eNodeB’ or ‘eNB’ . Note that if the base station 102A is implemented in the context of 5G NR, it may alternately be referred to as ‘gNodeB’ or ‘gNB’ . A next generation eNB (ng-eNB) may comprise an enhanced version of eNB that connects 5G UE to 5G core network using 4G LTE air interface.

As shown, the base station 102A may also be equipped to communicate with a network 100 (e.g., a core network of a cellular service provider, a telecommunication network such as a public switched telephone network (PSTN) , and/or the Internet, among various possibilities) . Thus, the base station 102A may facilitate communication between the user devices and/or between the user devices and the network 100. In particular, the cellular base station 102A may provide UEs 106 with various telecommunication capabilities, such as voice, SMS and/or data services. It will be appreciated that in various embodiments, the term network may be utilized to collectively refer to one or more devices and components that form the telecommunications network. For example, reference to the network sending or receiving data to/from a UE may refer to one or more portions of the core network of a cellular service provider and/or one or more base stations. In some such examples, data to send to the UE may be determined by core network components and then relayed to the UE via a base station. In other such examples, data to send to the UE may be determined and sent to the UE by a base station.

Base station 102A and other similar base stations (such as base stations 102B ... 102N) operating according to the same or a different cellular communication standard may thus  be provided as a network of cells, which may provide continuous or nearly continuous overlapping service to UEs 106A-N and similar devices over a geographic area via one or more cellular communication standards.

Thus, while base station 102A may act as a “serving cell” for UEs 106A-N as illustrated in FIG. 1, each UE 106 may also be capable of receiving signals from (and possibly within communication range of) one or more other cells (which might be provided by base stations 102B-N and/or any other base stations) , which may be referred to as “neighboring cells” . Such cells may also be capable of facilitating communication between user devices and/or between user devices and the network 100. Such cells may include “macro” cells, “micro” cells, “pico” cells, and/or cells which provide any of various other granularities of service area size. For example, base stations 102A-B illustrated in FIG. 1 might be macro cells, while base station 102N might be a micro cell. Other configurations are also possible.

In some embodiments, base station 102A may be a next generation base station, e.g., a 5G New Radio (5G NR) base station, or “gNB” . In some embodiments, a gNB may be connected to a legacy evolved packet core (EPC) network and/or to a NR core (NRC) network. In addition, a gNB cell may include one or more transition and reception points (TRPs) . In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs.

Note that a UE 106 may be capable of communicating using multiple wireless communication standards. For example, the UE 106 may be configured to communicate using a wireless networking (e.g., Wi-Fi) and/or peer-to-peer wireless communication protocol (e.g., Bluetooth, Wi-Fi peer-to-peer, etc. ) in addition to at least one cellular communication protocol (e.g., GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces) , LTE, LTE-A, 5G NR, 6G, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD) , et cetera) . The UE 106 may also or alternatively be configured to communicate using one or more global navigational satellite systems (GNSS, e.g., GPS or GLONASS) , one or more mobile television broadcasting standards (e.g., ATSC-M/H or DVB-H) , and/or any other wireless communication protocol, if desired. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

FIG. 2 illustrates user equipment 106 (e.g., one of the devices 106A through 106N) in communication with a base station 102, according to some embodiments. The UE 106 may be a  device with cellular communication capability such as a mobile phone, a hand-held device, a computer or a tablet, or virtually any type of wireless device.

The UE 106 may include a processor that is configured to execute program instructions stored in memory. The UE 106 may perform any of the method embodiments described herein by executing such stored instructions. Alternatively, or in addition, the UE 106 may include a programmable hardware element such as an FPGA (field-programmable gate array) that is configured to perform any of the method embodiments described herein, or any portion of any of the method embodiments described herein.

The UE 106 may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some embodiments, the UE 106 may be configured to communicate using, for example, 5G NR, CDMA2000 (1xRTT/1xEV-DO/HRPD/eHRPD) , 6G, or LTE using a single shared radio and/or GSM or LTE using the single shared radio. The shared radio may couple to a single antenna, or may couple to multiple antennas (e.g., for MIMO) for performing wireless communications. In general, a radio may include any combination of a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc. ) , or digital processing circuitry (e.g., for digital modulation as well as other digital processing) . Similarly, the radio may implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE 106 may share one or more parts of a receive and/or transmit chain between multiple wireless communication technologies, such as those discussed above.

In some embodiments, the UE 106 may include separate transmit and/or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol with which it is configured to communicate. As a further possibility, the UE 106 may include one or more radios which are shared between multiple wireless communication protocols, and one or more radios which are used exclusively by a single wireless communication protocol. For example, the UE 106 might include a shared radio for communicating using either of LTE or 5G NR (or LTE or 1xRTTor LTE or GSM or 6G) , and separate radios for communicating using each of Wi-Fi and Bluetooth. Other configurations are also possible.

FIG. 3 illustrates an example simplified block diagram of a communication device 106, according to some embodiments. It is noted that the block diagram of the communication device of FIG. 3 is only one example of a possible communication device. According to  embodiments, communication device 106 may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device) , a tablet and/or a combination of devices, among other devices. As shown, the communication device 106 may include a set of components 300 configured to perform core functions. For example, this set of components may be implemented as a system on chip (SOC) , which may include portions for various purposes. Alternatively, this set of components 300 may be implemented as separate components or groups of components for the various purposes. The set of components 300 may be coupled (e.g., communicatively; directly or indirectly) to various other circuits of the communication device 106.

For example, the communication device 106 may include various types of memory (e.g., including NAND flash 310) , an input/output interface such as connector I/F 320 (e.g., for connecting to a computer system; dock; charging station; input devices, such as a microphone, camera, keyboard; output devices, such as speakers; etc. ) , the display 360, which may be integrated with or external to the communication device 106, and cellular communication circuitry 330 such as for 5G NR, LTE, GSM, etc., and short to medium range wireless communication circuitry 329 (e.g., BluetoothTM and WLAN circuitry) . In some embodiments, communication device 106 may include wired communication circuitry (not shown) , such as a network interface card, e.g., for Ethernet.

The cellular communication circuitry 330 may couple (e.g., communicatively; directly or indirectly) to one or more antennas, such as antennas 335 and 336 as shown. The short to medium range wireless communication circuitry 329 may also couple (e.g., communicatively; directly or indirectly) to one or more antennas, such as antennas 337 and 338 as shown. Alternatively, the short to medium range wireless communication circuitry 329 may couple (e.g., communicatively; directly or indirectly) to the antennas 335 and 336 in addition to, or instead of, coupling (e.g., communicatively; directly or indirectly) to the antennas 337 and 338. The short to medium range wireless communication circuitry 329 and/or cellular communication circuitry 330 may include multiple receive chains and/or multiple transmit chains for receiving and/or transmitting multiple spatial streams, such as in a multiple-input multiple output (MIMO) configuration.

In some embodiments, as further described below, cellular communication circuitry 330 may include dedicated receive chains (including and/or coupled to, e.g., communicatively;  directly or indirectly, dedicated processors and/or radios) for multiple radio access technologies (RATs) (e.g., a first receive chain for LTE and a second receive chain for 5G NR) . In addition, in some embodiments, cellular communication circuitry 330 may include a single transmit chain that may be switched between radios dedicated to specific RATs. For example, a first radio may be dedicated to a first RAT, e.g., LTE, and may be in communication with a dedicated receive chain and a transmit chain shared with an additional radio, e.g., a second radio that may be dedicated to a second RAT, e.g., 5G NR, and may be in communication with a dedicated receive chain and the shared transmit chain.

The communication device 106 may also include and/or be configured for use with one or more user interface elements. The user interface elements may include any of various elements, such as display 360 (which may be a touchscreen display) , a keyboard (which may be a discrete keyboard or may be implemented as part of a touchscreen display) , a mouse, a microphone and/or speakers, one or more cameras, one or more buttons, and/or any of various other elements capable of providing information to a user and/or receiving or interpreting user input.

The communication device 106 may further include one or more smart cards 345 that include SIM (Subscriber Identity Module) functionality, such as one or more UICC (s) (Universal Integrated Circuit Card (s) ) cards 345.

As shown, the SOC 300 may include processor (s) 302, which may execute program instructions for the communication device 106 and display circuitry 304, which may perform graphics processing and provide display signals to the display 360. The processor (s) 302 may also be coupled to memory management unit (MMU) 340, which may be configured to receive addresses from the processor (s) 302 and translate those addresses to locations in memory (e.g., memory 306, read only memory (ROM) 350, NAND flash memory 310) and/or to other circuits or devices, such as the display circuitry 304, short range wireless communication circuitry 229, cellular communication circuitry 330, connector I/F 320, and/or display 360. The MMU 340 may be configured to perform memory protection and page table translation or set up. In some embodiments, the MMU 340 may be included as a portion of the processor (s) 302.

As noted above, the communication device 106 may be configured to communicate using wireless and/or wired communication circuitry. The communication device 106 may be configured to transmit a request to attach to a first network node operating according to the first RAT (e.g., 5G NR, 4G LTE, Bluetooth, Wi-Fi, et cetera) and transmit an indication that the  wireless device is capable of maintaining substantially concurrent connections with the first network node and a second network node that operates according to the second RAT (e.g., 5G NR, 4G LTE, Bluetooth, Wi-Fi, et cetera) . The wireless device may also be configured transmit a request to attach to the second network node. The request may include an indication that the wireless device is capable of maintaining substantially concurrent connections with the first and second network nodes. Further, the wireless device may be configured to receive an indication that dual connectivity with the first and second network nodes has been established.

As described herein, the communication device 106 may include hardware and software components for implementing the above features for supporting DGL transmissions. The processor 302 of the communication device 106 may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) . Alternatively (or in addition) , processor 302 may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array) , or as an ASIC (Application Specific Integrated Circuit) . Alternatively (or in addition) the processor 302 of the communication device 106, in conjunction with one or more of the other components 300, 304, 306, 310, 320, 329, 330, 340, 345, 350, 360 may be configured to implement part or all of the features described herein.

In addition, as described herein, processor 302 may include one or more processing elements. Thus, processor 302 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor 302. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, et cetera) configured to perform the functions of processor (s) 302.

Further, as described herein, cellular communication circuitry 330 and short range wireless communication circuitry 329 may each include one or more processing elements. In other words, one or more processing elements may be included in cellular communication circuitry 330 and, similarly, one or more processing elements may be included in short range wireless communication circuitry 329. Thus, cellular communication circuitry 330 may include one or more integrated circuits (ICs) that are configured to perform the functions of cellular communication circuitry 330. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, et cetera) configured to perform the functions of cellular communication circuitry 330. Similarly, the short range wireless communication circuitry 329 may include one or more ICs that are configured to perform the functions of short range  wireless communication circuitry 329. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, et cetera) configured to perform the functions of short range wireless communication circuitry 329.

FIG. 4 illustrates an example block diagram of a base station 102, according to some embodiments. It is noted that the base station of FIG. 4 is merely one example of a possible base station. As shown, the base station 102 may include processor (s) 404 which may execute program instructions for the base station 102. The processor (s) 404 may also be coupled to memory management unit (MMU) 440, which may be configured to receive addresses from the processor (s) 404 and translate those addresses to locations in memory (e.g., memory 460 and read only memory (ROM) 450) or to other circuits or devices.

The base station 102 may include at least one network port 470. The network port 470 may be configured to couple to a telephone network and provide a plurality of devices, such as UE devices 106, access to the telephone network as described above in FIGS. 1 and 2.

The network port 470 (or an additional network port) may also or alternatively be configured to couple to a cellular network, e.g., a core network of a cellular service provider. The core network may provide mobility related services and/or other services to a plurality of devices, such as UE devices 106. In some cases, the network port 470 may couple to a telephone network via the core network, and/or the core network may provide a telephone network (e.g., among other UE devices serviced by the cellular service provider) .

In some embodiments, base station 102 may be a next generation base station, e.g., a 5G New Radio (5G NR) base station, or “gNB” . In such embodiments, base station 102 may be connected to a legacy evolved packet core (EPC) network and/or to a NR core (NRC) network. In addition, base station 102 may be considered a 5G NR cell and may include one or more transition and reception points (TRPs) . In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs.

The base station 102 may include at least one antenna 434, and possibly multiple antennas, such as an array of antennas (see e.g., FIG. 12) . The at least one antenna 434 may be configured to operate as a wireless transceiver and may be further configured to communicate with UE devices 106 via radio 430. The antenna 434 communicates with the radio 430 via communication chain 432. Communication chain 432 may be a receive chain, a transmit chain or both. The radio 430 may be configured to communicate via various wireless communication  standards, including, but not limited to, 5G NR, LTE, LTE-A, GSM, UMTS, CDMA2000, Wi-Fi, etc.

The base station 102 may be configured to communicate wirelessly using multiple wireless communication standards. In some instances, the base station 102 may include multiple radios, which may enable the base station 102 to communicate according to multiple wireless communication technologies. For example, as one possibility, the base station 102 may include an LTE radio for performing communication according to LTE as well as a 5G NR radio for performing communication according to 5G NR. In such a case, the base station 102 may be capable of operating as both an LTE base station and a 5G NR base station. As another possibility, the base station 102 may include a multi-mode radio which is capable of performing communications according to any of multiple wireless communication technologies (e.g., 5G NR and Wi-Fi, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, etc. ) .

As described further subsequently herein, the BS 102 may include hardware and software components for implementing or supporting implementation of features described herein. The processor 404 of the base station 102 may be configured to implement or support implementation of part or all of the methods described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) . Alternatively, the processor 404 may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array) , or as an ASIC (Application Specific Integrated Circuit) , or a combination thereof. Alternatively (or in addition) the processor 404 of the BS 102, in conjunction with one or more of the other components 430, 432, 434, 440, 450, 460, 470 may be configured to implement or support implementation of part or all of the features described herein.

In addition, as described herein, processor (s) 404 may be comprised of one or more processing elements. In other words, one or more processing elements may be included in processor (s) 404. Thus, processor (s) 404 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor (s) 404. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, etc. ) configured to perform the functions of processor (s) 404.

Further, as described herein, radio 430 may be comprised of one or more processing elements. In other words, one or more processing elements may be included in radio 430. Thus,  radio 430 may include one or more integrated circuits (ICs) that are configured to perform the functions of radio 430. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, etc. ) configured to perform the functions of radio 430.

FIG. 5 illustrates an example simplified block diagram of cellular communication circuitry, according to some embodiments. It is noted that the block diagram of the cellular communication circuitry of FIG. 5 is only one example of a possible cellular communication circuit. According to embodiments, cellular communication circuitry 330 may be include in a communication device, such as communication device 106 described above. As noted above, communication device 106 may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device) , a tablet and/or a combination of devices, among other devices.

The cellular communication circuitry 330 may couple (e.g., communicatively; directly or indirectly) to one or more antennas, such as antennas 335 a-b and 336 as shown. In some embodiments, cellular communication circuitry 330 may include dedicated receive chains (including and/or coupled to, e.g., communicatively; directly or indirectly, dedicated processors and/or radios) for multiple RATs (e.g., a first receive chain for LTE and a second receive chain for 5G NR) . For example, as shown in FIG. 5, cellular communication circuitry 330 may include a modem 510 and a modem 520. Modem 510 may be configured for communications according to a first RAT, e.g., such as LTE or LTE-A, and modem 520 may be configured for communications according to a second RAT, e.g., such as 5G NR.

As shown, modem 510 may include one or more processors 512 and a memory 516 in communication with processors 512. Modem 510 may be in communication with a radio frequency (RF) front end 530. RF front end 530 may include circuitry for transmitting and receiving radio signals. For example, RF front end 530 may include receive circuitry (RX) 532 and transmit circuitry (TX) 534. In some embodiments, receive circuitry 532 may be in communication with downlink (DL) front end 550, which may include circuitry for receiving radio signals via antenna 335a.

Similarly, modem 520 may include one or more processors 522 and a memory 526 in communication with processors 522. Modem 520 may be in communication with an RF front end 540. RF front end 540 may include circuitry for transmitting and receiving radio signals. For example, RF front end 540 may include receive circuitry 542 and transmit circuitry 544. In  some embodiments, receive circuitry 542 may be in communication with DL front end 560, which may include circuitry for receiving radio signals via antenna 335b.

In some embodiments, a switch 570 may couple transmit circuitry 534 to uplink (UL) front end 572. In addition, switch 570 may couple transmit circuitry 544 to UL front end 572. UL front end 572 may include circuitry for transmitting radio signals via antenna 336. Thus, when cellular communication circuitry 330 receives instructions to transmit according to the first RAT (e.g., as supported via modem 510) , switch 570 may be switched to a first state that allows modem 510 to transmit signals according to the first RAT (e.g., via a transmit chain that includes transmit circuitry 534 and UL front end 572) . Similarly, when cellular communication circuitry 330 receives instructions to transmit according to the second RAT (e.g., as supported via modem 520) , switch 570 may be switched to a second state that allows modem 520 to transmit signals according to the second RAT (e.g., via a transmit chain that includes transmit circuitry 544 and UL front end 572) .

As described herein, the modem 510 may include hardware and software components for implementing the above features or for supporting DGL transmissions, as well as the various other techniques described herein. The processors 512 may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) . Alternatively (or in addition) , processor 512 may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array) , or as an ASIC (Application Specific Integrated Circuit) . Alternatively (or in addition) the processor 512, in conjunction with one or more of the other components 530, 532, 534, 550, 570, 572, 335 and 336 may be configured to implement part or all of the features described herein.

In addition, as described herein, processors 512 may include one or more processing elements. Thus, processors 512 may include one or more integrated circuits (ICs) that are configured to perform the functions of processors 512. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, et cetera) configured to perform the functions of processors 512.

As described herein, the modem 520 may include hardware and software components for implementing the above features for supporting DGL transmissions, as well as the various other techniques described herein. The processors 522 may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory  medium (e.g., a non-transitory computer-readable memory medium) . Alternatively (or in addition) , processor 522 may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array) , or as an ASIC (Application Specific Integrated Circuit) . Alternatively (or in addition) the processor 522, in conjunction with one or more of the other components 540, 542, 544, 550, 570, 572, 335 and 336 may be configured to implement part or all of the features described herein.

In addition, as described herein, processors 522 may include one or more processing elements. Thus, processors 522 may include one or more integrated circuits (ICs) that are configured to perform the functions of processors 522. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, et cetera) configured to perform the functions of processors 522.

FIG. 6 illustrates a network message 602 comprising a plurality of information elements (IEs) 604a, 604b, 604c, 604d (collectively referred to as IEs 604) . In various embodiments, a variety of network messages 602 composed of one or more information elements may be utilized for communication between different components. In various such embodiments, one or more network messages 602 of one or more formats may be exchanged between the one or more UEs and one or more network components to perform one or more procedures or techniques disclosed hereby. For example, predictive scheduling of resources may involve the exchange of several network messages 602 between UEs and/or a BS. It will be appreciated that the network message 602 and IEs 604 may come in a variety of formats and carry a variety of information. Oftentimes, various standards and technical specifications define the various network messages 602, IEs 604, and procedures, such as 3GPP technical specifications (e.g., TS 23.502, TS 22.261, , TS 38.214, TS 38.300, and TS 38.321) . Embodiments are not limited in this context.

Various techniques to support DGL transmissions scheduling for low latency communications, such as utilizing complimentary AI/ML models at UEs and BSs, are described in more detail below. Many embodiments disclosed hereby provide resource-efficient techniques to adapt to dynamically varying traffic using projected resource demands. Various embodiments utilize a dynamic grant-less (DGL) transmission scheme that synchronizes UEs and BSs including synchronization of allocated resources with incoming packets using complimentary AI and/or ML models at the UEs and BSs. For example, an ML model at the BS may predict the size and time of upcoming packet arrival using reports from the UE to align  with incoming packets at the UE, and then the BS allocates resources using the prediction. Further, a complimentary ML model at the UE may predict the size and time of upcoming packet arrival using historical packet arrival pattern and calculate the allocated resources simultaneously. Thus, future packet arrival profiles may be predicted for aperiodic traffic patterns with irregular packet arrival times and varying packet sizes.

In several embodiments, the UE reports the AI/ML model (s) to the BS to predict the size and/or time of upcoming packet arrivals, enabling the BS to assign UL resources without additional requests from the UE. Accordingly, the UE may be provided with resources for aperiodic uplink transmissions without the need for regular control signaling from the BS (e.g., via the physical downlink control channel (PDDCH) ) . The transmissions may be setup via initial configuration exchange and are adjusted using subsequent traffic configuration and/or channel updates (e.g., traffic pattern, channel quality, etc. ) . In some embodiments, the UE is implicitly informed about physical resource block (PRB) allocation of the upcoming packets based on PRB configuration messaging. In many embodiments, UE feedback may include a modified BSR, which may include a legacy BSR plus additional information (e.g., inter-arrival time between previous packet and/or current packet size) . This can allow both the UE and the BS to predict the occurrence and size of the next packet arrival in the UE buffer and for the UE and BS to both have a common understanding of the resource allocation. The DGL transmission techniques described hereby can work with legacy signaling framework alongside and AI/ML model at the UE and another AI/ML model at the BS. Further, enhanced signaling can be used to provide further inputs to AI/ML models for additional improvements.

In these and other ways, components/techniques described hereby may provide many technical advantages. For instance, the computer-based techniques of the current disclosure improve the functioning of a telecommunications system as compared to conventional approaches because the techniques enable DGL transmissions that can improve accessibility, reduce latency (e.g., scheduling latency) , lower overhead, and provide expanded capabilities for telecommunication systems versus conventional approaches. For example, as compared to 5G dynamic scheduling for aperiodic data arrival, the DGL techniques described hereby can avoid regular handshake delays associated with scheduling requests and UL grant exchange and reduce overall control signaling overhead (e.g., scheduling requests and downlink control information) . In another example, as compared to 5G configured grant transmissions, the DGL techniques described hereby can increase resource utilization, reduce latency through aligning  scheduled PRBs with packet arrivals at the UE, reduce media access control (MAC) buffer size requirements, reduce packet drop rate for delay critical applications with latency bounds, and increase reliability while reducing the number of repetition in shared resources in multi-user setup. Accordingly, embodiments disclosed hereby can be practically utilized to improve the functioning of a computer and/or to improve a variety of technical fields including telecommunications, computer networks, scheduling, resource utilization, low latency communications, URLLC, artificial intelligence, machine learning, and/or user experience.

FIGS. 7A and 7B illustrate exemplary block diagrams of various components for implementing DGL transmissions according to some embodiments. More specifically, FIG. 7A illustrates a block diagram of a UE 702 in conjunction with a BS 704 and FIG. 7B illustrates a block diagram of the BS 704 in conjunction with the UE 702 and a core network 734. In various embodiments, UE 702, BS 704, and core network 734 may operate to support DGL transmissions, such as by using complementary ML models (e.g., ML models 716, 726) . In the illustrated embodiment of FIG. 7A, UE 702 includes one or more packet generation processes 706, a buffer 708 with packets 710a, 710b, 710c (collectively referred to as packets 710) , buffer monitor 712, predictor 714 with ML model 716 and model trainer 722, prediction manager 718, and wireless communication manager 720. In the illustrated embodiment of FIG. 7B, BS 704 includes a predictor 724 with ML model 726, a prediction manager 728, a wireless communication manager 730, and a configuration administrator 732. Additionally, core network 734 includes one or more network functions 736. It will be appreciated that one or more components of FIGS. 7A and/or 7B may be the same or similar to one or more other components disclosed hereby. For example, BS 704 may be the same or similar to BS 102. In another example, UE 702 may be the same or similar to UE 106. In a further example, wireless communication manager 720 may include one or more portions of SOC 300 and/or cellular communication circuitry 330. Further, aspects discussed with respect to various components in FIGS. 7A and/or 7B may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. For example, model trainer 722 may be included in BS 704 or core network 734. Embodiments are not limited in this context.

In many embodiments, DGL transmissions may generally operate as follows with various aspects and/or alternatives of the operations being described in more detail below, such as with respect to FIGS. 7-19. In various embodiments, the UE may be configured with  parameters from grant-less uplink transmissions, such as applicable traffic class (logical channel ID) , AI/ML model class (also referred to as ML model) , triggers, fallback options, and the like. The configuration may include maximum and/or minimum configured allocation sizes (or configured grant sizes, although the grants are not communicated to the UEs) and resource allocation policy for fixed (legacy) , predicted traffic, and the like. The UE may train the ML model with incoming packet arrivals to predict future packet arrivals including time of arrival and size of packets. The UE may share the trained model with the base station. The UE may share required information to perform inferences for prediction by multiplexing with uplink data (e.g., modified BSR (including packet inter arrival time) . In some embodiments, an ML model may be used to predict packet size and packet arrival times at both the BS and the UE. The PRB allocation for the predicted packet may be performed using channel quality information (CQI) that is available to the UE in the corresponding transmit slot. In some embodiments, there may be a CQI prediction, and the predicted CQI may also be used for PRB allocation. In various embodiments, ML models may use one or more of historical traffic data (e.g., packet sizes, inter arrival times) and allocations (CQIs, packet errors, retransmissions, hybrid automatic repeat request (HARQ) , UL data rate, etc. ) to predict future PRBs. In many embodiments, the ML models may have some distortion (e.g., ) to either account for report quantization and/or to increase user privacy via intentional addition of jitter. The distorted model may be shared with the BS. Using this, the BS can predict future packet arrivals and schedule uplink resources to align with them (plus any required fixed processing delay -a worst case processing delay can be considered) . Further, the BS and UE have an implicit common understanding of the allocated uplink resources for the configured application or logical channel.

Many embodiments utilize a modified BSR that includes one or more of the following. Some embodiments may include a modified BSR for applications/logical channels utilizing the grant-less uplink method. In some such embodiments, this is multiplexed with a legacy BSR for legacy traffic. In various embodiments, additional fields for one or more of last packet inter-arrival time, prediction error correction (e.g., for the case of multiple packet arrivals before grant time) , and for model updates, such as new model ID, model state (e.g., for recursive models) , model accuracy, and the like.

Several embodiment may involve one or more of the UE providing the BS with traffic characteristics for a configured application or logical channel and the BS performing model  training and providing the UE with a prediction model that also incorporates the BS scheduling constraints. In some embodiments, the BS can get some information from network functions (e.g., application function (AF) , network exposure function (NEF) , policy control function (PCF) , session management function (SMF) , etc. ) in the core network about packet arrival statistics for model training. In some such embodiments, the user plane function (UPF) may be responsible for delivery of the ML model to the BS and the UE. In various embodiments, the BS may collect data arrival statistics, such as with a fine resolution BSR report which includes packet sizes and packet arrival times. In many embodiments, the BS may train the model based on its scheduling policy (e.g., resource pooling, such as for multi-user scenarios described with respect to FIGS. 12A and 12B) . In several embodiments, the training of models may be performed offline and may be performed by one or more of the UE, the UE vendor, the modem chipset vendor, the network, or a third party. In various embodiments, the UE can get the model from the application layer. For example, the model may be embedded in a modem model repository or the UE can receive the model from the network or AF.

Referring back to FIG. 7A, the UE 702 may include one or more packet generation processes 706, such as applications, that generate data for transmission to BS 704. This data for transmission may be stored in buffer 708 as data packets 710 until resources are available for usage by wireless communication manager 720 to transmit the data packets 710 to the BS 704. In some embodiments, the buffer 708 may comprise a MAC buffer. The buffer monitor 712 may monitor characteristics regarding packets in the buffer 708 (e.g., interpacket arrival time, packet size, etc. ) . One or more of these characteristics may be utilized by the predictor 714 to project resource demands using ML model 716 (e.g., size and/or timing of future data packets) . Additionally, one or more of these characteristics may be provided to the BS 704 via wireless communication manager 720 to enable the BS 704 to determine projected resource demands using a complimentary ML model (e.g., ML model 726) . The prediction manager 718 may be responsible for configuring one or more aspects of the UE 702 to perform DGL transmissions, such as based on configuration data received from the BS 704 via wireless communication manager 720. Additionally, or alternatively, the prediction manager 718 may monitor prediction performance and trigger/request activation or deactivation of DGL transmissions based thereon. In various embodiments, the prediction manager 718 may receive model identifiers, model updates, or the models themselves (e.g., from BS 704) and implement them in predictor 714. In some embodiments, the model trainer 722 may be utilized to train ML  model 716 based on historical resource demands for uplink wireless communications by one or more UEs and/or configuration data, such as data from buffer monitor 712, prediction manager 718, and/or received from BS 704.

Referring to FIG. 7B, similar to UE 702, the BS 704 may utilize predictor 724 to determine projected resource demands using ML model 726. In many embodiments, the predictor 724 may utilize data received from UE 702 (e.g., via wireless communication manager 730) and/or network functions 736 of core network 734 to determine the projected resource demands with ML model 726. In various embodiments, the configuration administrator 732 may be utilized to determine the appropriate configuration for performing DGL transmissions, such as based on data received from one or more of UE 702 and core network 734. In various such embodiments, the configuration administrator 732 may utilize wireless communication manager 730 to communicate the configuration to UE 702. The prediction manager 728 may monitor prediction performance and trigger/request activation or deactivation of DGL transmissions based thereon. In some embodiments, the prediction manager 728 may receive model identifiers, model updates, or the models themselves (e.g., from UE 702 or core network 734) and implement them in predictor 724.

Generally, configuration, activation, and/or deactivation procedures for DGL transmissions and the ML models 716, 726 may include one or more of the following. Regarding model generation, in some embodiments, the model may be stored at the network with model ID so that the BS 704 can be configured through MAC-CE or BSR reports. The model may be updated, modified, and/or configured (such as resource start index, size or resources, etc. ) depending on available resources. Regarding model monitoring, in various embodiments, the UE 702 may monitor accuracy of the prediction and latency (e.g., via prediction manager 718) since it has exact packet arrival statistics. The UE 702 may report accuracy and/or latency to the BS 704. The BS 704 may monitor resource utilization (e.g., via prediction manager 728) and change configurations (e.g., via configuration administrator 732) , such as by changing one or more of the model, the duration of DGL transmissions, and resource pools.

Regarding model training/retraining, in many embodiments, the UE 702 may train the models online depending on accuracy. In many such embodiments, the UE 702 may provide the models/updated models to the BS 704. The UE 702 may monitor data packet size and arrival prediction accuracy while transmitting (e.g., while performing DGL transmission) . In several  embodiments, the BS 704 may request retraining to meet certain targets (e.g., a resource utilization target) . In various embodiments, the BS 704 may monitor resource utilization and/or received packet sizes to calculate prediction accuracy.

In some embodiments, model training may be done at the UE (e.g., via model trainer 722) , such as because the UE has exact traffic statistics for a specific application/logical channel. In various embodiments, the training may be offline and/or may be done by the UE vendor. In some embodiments, the UE vendor may collect training data using test devices of over non-3GPP links. The trained model may be used per UE vendor specific scheduling. When deciding the training host (e.g., on the UE or application server) , the privacy of data may be protected (e.g., via intentional distortion) . In many embodiments, to optimize network operation, a multi-vendor model training may be utilized. In this case a standardized data repository (e.g., data lake) may be created to support training the models on various servers. In embodiments in which training data is location sensitive, training data collection may be left to the UE vendor.

In several embodiments, model training may be done at the UE, which may incorporate its scheduling strategy with model training. In several such embodiments, all non-UE specific (e.g., public) data may be collected by 3GPP entities or public servers that include network measurements essential for optimum network operations. In some embodiments, the network may be responsible and cooperate with UE vendors to collect training data (e.g., in the data lake) . The trained model may be shared with UE vendors application developers before chipset development and/or updated later when the application is in use.

Regarding model activation, in several embodiments, the UE 702 may activate DGL transmissions by sending a MAC-CE or BSR. In various embodiments, the BS 704 may activate DGL transmissions via RRC configuration or DCI. Regarding model deactivation, in many embodiments, the UE 702 may deactivate the model and fallback to periodic grants or stop transmission when prediction error exceeds a given threshold or there is no uplink traffic by sending a MAC-CE or BSR. In some embodiments, the BS 704 may deactivate the model when resource utilization drops below default periodic grants or based on a threshold by sending MAC-CE, DCI, and/or an RRC message.

FIG. 8 illustrates various aspects of dynamic grant-less (DGL) transmissions according to some embodiments. The illustrated embodiment includes a schematic 800 showing the exchange of messages 810a, 810b, 810c, 810d, 810e, 810f, 810g, 810h (collectively  referred to as messages 810) corresponding to DGL transmissions between a BS 802 and a UE 804 in conjunction with contents of a UE data buffer 806. Schematic 800 includes a time axis 808 with time increasing towards the right of the page. Accordingly, schematic 800 illustrates the exchange of messages 810 and the contents of UE data buffer 806 over time in an exemplary embodiment of DGL transmissions. The contents of the UE data buffer 806 over time include data packets 812a, 812b, 812c, 812d (collectively referred to as data packets 812) . Additionally, the boxes correspond to transmission slots for sending and receiving signals between the BS 802 and UE 804 with the shaded boxes corresponding to data packet transmissions. Schematic 800 also includes PRB alignment 814 illustrating the alignment of PRBs with packet arrivals plus any required fixed processing delays. Further, schematic 800 illustrates a packet size 816 of data packet 812a and an interpacket arrival time 818 between data packet 812a and data packet 812b. It will be appreciated that one or more components of FIG. 8 may be the same or similar to one or more other components disclosed hereby. For example, UE data buffer 806 may be the same or similar to buffer 708. In another example, data packet 812a may be the same or similar to packet 710a. Further, aspects discussed with respect to various components in FIG. 8 may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

In various embodiments, DGL transmissions described with respect to schematic 800 may be utilized with aperiodic packet arrival times and variable packet sizes to provide a grant-less transmission scheme for variable data rate traffic to support low latency application and provide better resource utilization. Initially, the UE 804 may transmit message 810a to BS 802. Message 810a may include a DGL configuration request with a model or a model identifier. In response, the BS 802 may send message 810b to UE 804 with the DGL configuration. In many embodiments, message 810b may comprise an RRC message. In some embodiments, message 810b may include an acknowledgement. The DGL configuration may be utilized, at least in part, to align PRBs with packet arrivals plus any required fixed processing delay (e.g., processing delay of ML prediction, scheduling delay, etc. ) .

The UE 804 may monitor packet size 816 and interpacket arrival time 818 of packets to implement DGL transmissions. Further, the UE 804 may report the interpacket arrival time 818 to the BS 802. For example, a modified BSR report may be utilized to report the interpacket arrival time 818 to the BS 802. In many embodiments, data packets may be  transmitted to the BS 802 with the modified BSR. For example, messages 810c, 810d, 810e, 810h may include the modified BSR with corresponding interpacket arrival times and data packets 812a, 812b, 812c, 812d, respectively. As shown in the illustrated embodiment, there is no scheduling requests or resource grants explicitly communicated via the messages 810 with DGL transmissions. Instead, complementary ML models at the BS 802 and UE 804 may determine projected resource allocations and utilize the projected resource allocations how/when to transmit and receive uplink wireless transmissions. Using the projected resource allocations, UE 804 is able to transmit the data packets 812 and BS 802 is able to receive the data packets 812 with reduce latency.

The UE 804 may send model updates to the BS 802 based on various parameters, such as prediction performance or traffic profiles. For example, UE 804 may determine a new traffic profile and send a model update in message 810f. In various embodiments, the model update may include a new model or a new model identifier for the BS 802 to utilize. Additionally, the UE 804 may utilize the new model indicated in message 810f. In response, the BS 802 may transmit message 810g to the UE 804. In some embodiments, message 810g may confirm the new model has been configured. Additionally, or alternatively, the message 810g may provide one or more configuration parameters for the new model. Subsequently, the UE 804 may utilize the new model to transmit message 810h with data packet 812d and the modified BSR and BS 802 may utilize the new model to determine when/how to receive the data packet 812d and the modified BSR in message 810h.

In several embodiments, the packet size at time, t, may be defined as D_t and the interpacket arrival time between t and t-1 may be defined as ΔT_t. Accordingly, the UE 804 can have a trained ML model for packet size prediction, andwhere w is a window size of prior packet arrivals. In some embodiments, these models may be replaced by models that predict allocated PRBs, directly. In many embodiments, the BS may share the start index of resources or pool of resources, such as via RRC configuration or PDCCH. As will be described in more detail below, such as with respect to FIGS. 12 and 13, the UE and BS may only predict the size of the resource.

The modified buffer report may include the last interpacket arrival time, ΔT_t, in addition to the current buffer status report. The BS may calculate the historical packet sizes using buffer status reports, Bt, with D_t= (B_t-B_t-1) +R_t where R_t is the received data at  BS in slot t. The BS and UE may predict the next packet size viaand the expected time viaThe allocation size (or grant size) can be given bywherein MCS is the modulation and coding scheme. In some embodiments, another a separate model may be utilized to determine the allocation size. In many embodiments, the models may be trained to account for various delays, such as buffer report receive delay at the BS and processing delays. For example, the models can be trained with the constraints of buffer report receive delay at BS plus processing delay < minimum packet inter-arrival time. In other embodiments, packet size and arrival time may be predicted, whereas conventional CQI may be used to identify PRB size. The above description is with both PRB size and timing estimation under BS and single UE scheduling, however, extensions, such as for multi-user scenarios are described in more detail below (e.g., FIGS. 12 and 13) .

In some embodiments, packet arrival times may be periodic while the packet size is variable. This type of scenario may be useful for variable data size but periodic transmission or for complexity reduction. In such embodiments, packet arrival time predictions are not needed. Accordingly, the UE may include a trained model for packet size and PRB predictionwhere w is window size. Otherwise, the system may operate in a similar manner to embodiments with packet size and arrival time predictions.

In some embodiments, packet arrival times may be aperiodic while the packet size is fixed. This type of scenario may be useful for variable packet arrival time but fixed packet sizes. In such embodiments, packet size predictions are not needed. Accordingly, the UE may include a trained model for packet size and PRB predictionwhere w is window size. Otherwise, the system may operate in a similar manner to embodiments with packet size and arrival time predictions.

FIG. 9 illustrates a process diagram 900 for DGL transmissions according to some embodiments. Process diagram 900 includes a UE 902 and a BS 904. In various embodiments, process diagram 900 may illustrate various operations performed (e.g., process 910, process 914, process 918) and messages sent and/or received (messages 906a, 906b, 906c, 906d, 906e, 906f, 906g, 906h (collectively referred to as messages 906) ) , and packet arrivals 908, 912, 916, 920 to implement DGL transmissions. It will be appreciated that one or more components of  FIG. 9 may be the same or similar to one or more other components disclosed hereby. For example, UE 902 may be the same or similar to UE 702. In another example, BS 904 may be the same or similar to BS 704. In yet another example, one or more of messages 906a, 906b may be the same or similar to one or more of messages 810a, 810b, respectively. Further, aspects discussed with respect to various components in FIG. 9 may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

In the illustrated embodiment, UE 902 may transmit message 906a to BS 904. Message 906a may include a DGL transmission request with ML model ID. The BS 904 may utilize the ML model ID to implement the appropriate model that is complimentary to the ML model utilized by the UE 902. In response to message 906a, the BS 904 may transmit message 906b to UE 902 with DGL transmission configuration information. In some embodiments, message 906b may be an RRC configuration or PDCCH message. In response to message 906b, UE 902 may transmit message 906c to BS 904. Message 906c may include a feedback acknowledgement or negative-acknowledgement. In various embodiments, once DGL transmissions are configured, the UE 902 may utilize an ML model for determining projected resource demands including pack and PRB predictions and the BS 904 may utilize an ML model for determining PRB predictions.

Subsequently, at packet arrival 912, a data packet may arrive in the buffer of UE 902. In response, UE 902 may send message 906d to BS 904 including the data packet and the modified BSR with the last interpacket arrival time. At process 914, the BS 904 may utilize the information in message 906d to predict the PRB size for the next data packet. A complimentary prediction may also occur at the UE 902. When the next data packet arrives in the buffer of UE 902 at packet arrival 916, it may be transmitted to and received by the BS 904 as message 906e based on the complimentary projected resource demands. Similarly, at process 918, the BS 904 may utilize the information in message 906e to predict the PRB size for the next data packet and a complimentary prediction may also occur at the UE 902. When the next data packet arrives in the buffer of UE 902 at packet arrival 920, it may be transmitted to and received by the BS 904 as message 906f based on the complimentary projected resource demands.

Message 906g may be transmitted to BS 904 by UE 902 in response to a new traffic profile. The message 906g may include a ML model update corresponding to the new traffic profile. In some embodiments, message 906g may include a different model ID. In response to  message 906g, the BS 904 may transmit message 906h to UE 902 with DGL transmission configuration information. In some embodiments, message 906h may be an RRC configuration or PDCCH message. In response to message 906h, UE 902 may transmit message 906i to BS 904. Message 906i may include a feedback acknowledgement or negative-acknowledgement.

FIGS. 10A and 10B illustrate various aspects of handling prediction errors according to some embodiments. FIGS. 10A and 10B include a UE 1002, a BS 1004 and various data packets, processes, and messages associated with prediction errors. More specifically, FIG. 10A includes process diagram 1000a that illustrates aspects of packet size prediction errors and FIG. 10B includes process diagram 1000b that illustrates aspects of packet arrival time prediction errors. In various embodiments, each of the messages 1008, 1016a, 1016b, 1026a, 1026b may include a modified BSR and data, unless the data is unavailable due to a prediction error. It will be appreciated that one or more components of FIGS. 10A and/or 10B may be the same or similar to one or more other components disclosed hereby. For example, UE 1002 may be the same or similar to UE 702. In another example, BS 1004 may be the same or similar to BS 704. Further, aspects discussed with respect to various components in FIGS. 10A and/or 10B may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

In many embodiments, there may be four cases for prediction inaccuracy at packet size estimation error and inter-arrival estimation error. Since the projected resource demands are two sided (i.e., UE and BS determinations) and prediction errors can occur, mechanisms to fix the errors, show that the BS can resolve them, and/or the UE can fix them, such as with extra signaling, are described below.

Referring to FIG. 10A, in some instances, the size of data packet 1012 may be larger than the estimated packet size 1014a such thatIn the illustrated embodiment, the estimated packet size 1014a is determined based on parameters associated with the previous packet, data packet 1006 (e.g., interpacket arrival time) . These parameters may be communicated to BS 1004 in message 1008. In instances in which the estimated packet size is smaller than the actual packet size, the UE buffer (e.g., MAC buffer) will have remaining data, B_t＞0, after transmission of message 1016a. The remaining data may be sent in the following transmission of data packet 1020 in message 1016b. This type of scenario will only  increase packet transmission latency, as the BS can calculate actual packet size via D_t= (B_t-B_t-1) +R_t so the next prediction is accurate.

In various instances, the size of data packet 1012 may be smaller than the estimated packet size 1014b such thatIn the illustrated embodiment, the estimated packet size 1014b is determined based on parameters associated with the previous packet, data packet 1006 (e.g., interpacket arrival time) . These parameters may be communicated to BS 1004 in message 1008. In instances in which the estimated packet size is larger than the actual packet size, some allocated resources will be wasted since R_t＜G_t (e.g., resource allocated for message 1016a) . However, the BS can calculate the actual packet size via D_t= (B_t-B_t-1) +R_t without any error.

Referring to FIG. 10B, in some instances, the arrival time of data packet 1022 (i.e., data packet 1022a and/or data packet 1022b) may be earlier than the estimated arrival time 1024. In the illustrated embodiment, the estimated arrival time 1024 is determined based on parameters associated with the previous packet, data packet 1006 (e.g., interpacket arrival time) . These parameters may be communicated to BS 1004 in message 1008. In instances in which the estimated arrival time 1024 is later than the actual packet arrival time (e.g., data packet 1022a and/or data packet 1022b) , the BS is able to correct inter-arrival time with ΔT_t. If multiple data packets arrive early (e.g., data packet 1022a and data packet 1022b) , then the BS 1004 may consider these packets as a single packet. To synchronize, the UE 1002 can utilize the sum of these packets to estimate the next packet estimation (i.e., for data packet 1030) as the BS would do. Alternatively, the UE may update the BS with the error amount, E, such as in message 1026a.

In various instances, the arrival time of data packet 1022 (i.e., data packet 1022c) may be later than the estimated arrival time 1024. In the illustrated embodiment, the estimated arrival time 1024 is determined based on parameters associated with the previous packet, data packet 1006 (e.g., interpacket arrival time) . These parameters may be communicated to BS 1004 in message 1008. In instances in which the estimated arrival time 1024 is earlier than the actual packet arrival time (e.g., data packet 1022c) , the BS assumes that no packet is received at the UE, both the UE and BS may fall back to a default grant size or periodic grants until the UE restarts the process, or DGL transmission is terminated.

FIG. 11 illustrates a process diagram 1100 of various aspects of DGL transmissions according to some embodiments. Process diagram 1100 includes a UE 1102 and a BS 1104. In  various embodiments, process diagram 1100 may illustrate various messages sent and/or received to implement DGL transmissions. It will be appreciated that one or more components of FIG. 11 may be the same or similar to one or more other components disclosed hereby. For example, message 1106a may be the same or similar to message 810a or message 906a. In another example, message 1106b may be the same or similar to message 810b or message 906b. In yet another example, message 1106c may be the same or similar to message 810c or message 906c. In yet another example, message 1106d may be the same or similar to message 810e or message 906f. In yet another example, message 1106e may be the same or similar to message 810f or message 906g. Further, aspects discussed with respect to various components in FIG. 11 may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

Additional details on signaling associated with DGL transmissions are described with respect to FIG. 11. Generally, message 1106a may include a DGL transmissions request with model ID transmitted from the UE 1102 to the BS 1104. Message 1106b may include an RRC configuration with DGL transmission configuration (e.g., duration of the scheme, resource indexes and pools, ACKs etc. ) transmitted from the BS 1104 to the UE 1102, such as in response to message 1106a. Message 1106c may include a MAC CE activation with modified BSR (e.g., including interpacket arrival time) . Message 1106d may include an uplink wireless transmission comprising an uplink data transmission having a data packet and a modified BSR. Message 1106e may include a DGL model configuration update.

In many embodiments, the AI/ML model is trained to predict future packet arrivals at the UE (e.g., in the MAC buffer) including time of arrival and/or size of data packets. In various embodiments, model training may be performed at one or more of the UE, the UE vendor, the chipset vendor and the network using exact data traffic statistics such as for a specific application or traffic profile. In several embodiments, each of the models may be associated with a unique model ID. The datasets for training may be created based on any of these scenarios. In some embodiments, the datasets for training may be created over non-3GPP links.

In various embodiments, the trained models may be used to calculate allocated PRBs for the UE which are aligned with packet arrivals in the MAC buffer. In several embodiments, the trained models may be used to calculate uplink PRBs for the UE which also may be aligned  with estimated packet arrivals in the MAC buffer of the UE. In many embodiments, the models can be per application or logical channel, which may have data from multiple applications. In some embodiments, one or more new logical channels, which support DGL transmissions, may be utilized. These logical channels may be used with a single application or multiple applications.

In several embodiments, the UE may share the model and/or model updates with the

BS via scheduling request occasions (SROs) , MAC CE, or PUCCH. In many embodiments, the BS may obtain required information from AI/ML inference through reports appended to the uplink data packets (e.g., modified BSR) . The models may utilize historical packet arrival profile and historical allocated PRBs/configs or CQIs (e.g., for opportunistic transmission when CQI is good) , packet errors (e.g., for estimating retransmission amount) , retransmission (e.g., for more accurate PRB estimation) , et cetera to predict future PRBs. In some embodiments, the models may have some distortion to reduce complexity and/or increase privacy. For example, the shared model may have some added distortion, with one or more of quantization of data arrival time, combining multiple arrivals as a single arrival, and some intentional jitter. The distorted model may be shared with the BS.

In various embodiments, a new RRC or PDCCH configuration may be utilized and include one or more of a maximum/minimum configured grant size, resources in dedicated channel, resources in shared channel, a model update with defined periodicity, a start index of resources in time and/or frequency to avoid conflicts and improve channel utilization, a model configuration request, a model configuration acknowledgement, a model parameter update, trigger conditions, et cetera. In many embodiments, a new report structure (e.g., modified BSR) may be utilized and include one or more of an additional fields with legacy buffer status report, a structure that enables multiplexing of low latency traffic with regular traffic, a last packet inter-arrival time, a prediction error correction term, E (for the case of multiple packet arrivals before estimated arrival time) , a model update such as a new model ID, model state (for recursive models) , model accuracy, et cetera.

FIGS. 12A and 12B illustrate various aspects of contention-free provisioning for multi-user DGL transmissions according to some embodiments. More specifically, FIG. 12A illustrates aspects of frequency domain resource pooling 1200a and FIG. 12B illustrates aspects of time domain resource pooling 1200b. It will be appreciated that one or more components of  FIGS. 12A and/or 12B may be the same or similar to one or more other components disclosed hereby. Further, aspects discussed with respect to various components in FIGS. 12A and/or 12B may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

Referring to FIG. 12A, in the illustrated embodiment, the frequency domain resource pooling 1200a may include a frequency axis 1202 and a time axis 1204 with a plurality of time slots 1206 extending along the time axis 1204. Further, different frequency bands may be allocated per time slot to each of UE1, UE2, and UE3. In various embodiments, with frequency domain resource pooling, the BS may provision frequency domain resource pools to each UE that is configured with uplink DGL transmissions. The resource pools can be allocated in the frequency domain as non-overlapping resource blocks such that when a UE and a BS jointly predict uplink packet transmission time, packet collision can be avoided. In some embodiments, when a UE does not have any upcoming uplink packet transmissions within a given time slot and/or PRB (i.e., prediction assumes no packet arrival in the uplink buffer) , then the BS may schedule other UEs in the unused PRBs within the assigned resource pool of the UE. For example, if UE3 has no upcoming uplink packet transmissions within the second time slot, then UE1 may be assigned the resource pool labeled with UE3 in the second time slot.

As shown in frequency domain resource pooling 1200a, in order to provide frequency diversity, each frequency domain resource pool per UE may be rotated and/or interleaved. In many embodiments, the frequency resource pool configuration may be communicated by the BS to the UE via an RRC message (e.g., message 1106b) and can be reconfigured periodically (e.g., via message 1106e) . In some embodiments, the configuration, or reconfiguration, of the resource pool per UE may be based on the performance of the historical uplink DGL transmission statistics and/or performance.

In many embodiments, the model training for packet arrival time and/or PRB prediction may be performed within the pre-configured resource pool per UE (i.e., the training operation is performed per UE and its assigned frequency domain resource pool) . In an additional, or alternative, embodiment, the resource pool may be a design parameter that is obtained at the output of the model. In scenarios in which the predicted packet size and hence the required PRB per predicted packet is larger than the pre-configured resource pool, the BS and UE may use the frequency domain resource pool for the same UE that is pre-configured in  the upcoming time slot. In another option, the BS can schedule additional PRBs in the corresponding (i.e., predicted) time slot for the UE, which can be communicated to the UE in PDCCH. In yet another option, a common resource pool can be defined by the BS such that each UE that is required to transmit an additional bit sequence (i.e., code-blocks or code-block groups) selects the PRBs within the common resource pool which might be prone to contention.

Referring to FIG. 12B, in the illustrated embodiment, the time domain resource pooling 1200b may include frequency axis 1202 and time axis 1204 with a plurality of time slots 1206 extending along the time axis 1204. Further, different ones of UE1, UE2, and UE3 may be allocated to each time slot. In various embodiments, with time domain resource pooling the procedures described above with respect to frequency domain pooling may be similarly utilized. In time domain resource pooling, the BS may provision time domain resource pools to each UE that is configured with uplink DGL transmissions. As shown in time domain resource pooling 1200b, the resource pools may be allocated in time domain non-overlapping resource blocks so that when a UE and BS jointly predict uplink packet transmission time, packet collisions can be avoided.

Similar to the frequency domain resource pooling, when a UE does not have any upcoming uplink packet transmissions within a given time slot and/or PRB (i.e., prediction assumes no packet arrival in the uplink buffer) , then the BS may schedule other UEs in the unused PRBs within the assigned resource pool of the UE. For example, if UE3 has no upcoming uplink packet transmissions within the fourth time slot, then UE1 may be assigned the resource pool labeled with UE3 in the fourth time slot.

In many embodiments, the model training for BSR and/or PRB prediction may be performed within the pre-configured resource pool per UE (i.e., the training operation is performed per UE and its assigned time domain resource pool) . In an additional, or alternative, embodiment, the resource pool may be a design parameter that is obtained at the output of the model. In scenarios in which the predicted packet size and hence the required PRB per predicted packet is larger than the pre-configured resource pool, the BS and UE may use the time domain resource pool for the same UE that is pre-configured in the upcoming time slot. In another option, the BS can schedule additional PRBs in the corresponding (i.e., predicted) time slot for the UE, which can be communicated to the UE in PDCCH. In yet another option, a common resource pool can be defined by the BS such that each UE that is required to transmit  an additional bit sequence (i.e., code-blocks or code-block groups) selects the PRBs within the common resource pool which might be prone to contention.

In some embodiments, hybrid frequency-time domain pooling may be utilized. For example, the frequency and time domain resource pools can be multiplexed together and the procedures described above can be modified accordingly. In many embodiments, the model may be trained or selected based on the above considerations. The resource pooling techniques described hereby can provide a contention free solution with high reliability.

FIG. 13 illustrates various aspects of contention-based provisioning for multi-user DGL transmissions according to some embodiments. The illustrated embodiment includes a BS 1302 with one or more antenna 1304a, 1304b, 1304c (collectively referred to as antenna 1304) and one or more UEs 1306a, 1306b, 1306c (collectively referred to as UEs 1306) with corresponding antenna 1308a, 1308b, 1308c, respectively. It will be appreciated that one or more components of FIG. 13 may be the same or similar to one or more other components disclosed hereby. For example, UE 1306a may be the same or similar to UE 702. In another example, BS 1302 may be the same or similar to BS 704. Further, aspects discussed with respect to various components in FIG. 13 may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

In various embodiments, the model for a UE may end up estimating the same PRB assigned to another UE. In various such embodiments, a multi-user (MU) multiple-input multiple-output (MIMO) technique may be utilized to avoid collisions. For example, a first user can send pilots on a resource element while other users send pilots on other resource elements. Based on the correlation between users using pilots, resources can be proactively provided for contention free scheduling. In such embodiments, the network may utilize a precoder (given the channel model of each user is known to the network) to differentiate the data from each user. A combination of one or more of frequency, time, and spatial resources can be considered. Spatial resources may correspond to using different one of the beam form by antennas 1304 for communicating with different UEs 1306.

In some embodiments, a random offset may be utilized. For example, the predicted uplink time domain scheduling (and/or PRB scheduling) can be configured with a random offset in time per UE in order to reduce the number of collisions. Depending on the collision performance/statistics, the random offset parameters per UE may be reconfigured by the BS  and send to the UE. In some embodiments, the random offset may include a multiple of the transmission time interval (TTI) .

In many embodiments, BS centric scheduling may be utilized. For example, when the BS, through its ML model packet arrival (and PRB) prediction operation, may identify that multiple UEs have overlapping packet scheduling prediction (in time, frequency, and/or space) , then the BS may switch to proactive PRB configuration for the UEs that have overlapping uplink PRB allocations. The BS may then configure new resources to these UEs, such as through PDDCH. In some embodiments, the reconfiguration message may provide an orthogonal PRB allocation to the selected UEs. In some such embodiments, the BS may only inform the UEs that their predicted transmission will collide with other (i.e., proactive NACK) so that the UE can simply add an offset in its predicted PRBs. When the BS predicts the PRBs, it can proactively resolve conflicts. This can reduce collisions and increase reliability. In several embodiments, a proactive model based on PRB prediction may increase resource utilization by reducing the number of repetition for highly reliable communications.

In various embodiments, the ML model may be trained with an input feature of the number of collisions to predict PRBs at both the BS and UE side to increase the probability of successful transmission. In various such embodiments, data may be generated from application, device, et cetera with some network measurements under a test scenario. In some embodiments, the data may be collected from the test devices over non-3GPP links.

FIG. 14 illustrates various aspects of using one or more network function (s) 1406 to support DGL transmissions according to some embodiments. The illustrated embodiment includes one or more UEs 1408a, 1408b, 1408c (collectively referred to as UEs 1408) , the one or more network function (s) 1406, and a core network 1402 with ML model 1404. It will be appreciated that one or more components of FIG. 14 may be the same or similar to one or more other components disclosed hereby. For example, network function (s) 1406 may be the same or similar to network functions 736. In another example, core network 1402 may be the same or similar to core network 734. Further, aspects discussed with respect to various components in FIG. 14 may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

In some embodiments, the network function (s) 1406 (e.g., application function (AF) ) may provision the network with various parameters. The provisioning capability may allow an  external party to provision the information, such as expected UE behavior and service specific parameters or virtual network group information to the other network function (s) 1406. The expected UE behavioral information may include information of expected UE movement and communication characteristics. Further, the network may expose the current and predicted network conditions to the application function. For example, based on operator policy, the network may be able to provide means to predict and expose predicted network condition changes (e.g., bitrate, latency, reliability) per UE to an authorized third party.

Accordingly, in some embodiments, the AF may use data provided by the UE (e.g., application level data) and the network to train a model to predict future packet arrivals including time of arrival and size of packets. In various embodiments, the AF may share the trained model (e.g., ML model 1404) with the UE and network. In several embodiments, the AF may share required information for determining projected resource demands with the model (i.e., performing inferences) .

In various embodiments, a DGL option may be added to network slice attributes to indicate if DGL is allowed for a specific slice or not. In various such embodiments, each network slice may be an isolated end-to-end network tailored to fulfil specific requirements (e.g., of a set of one or more applications and/or set of one or more services) . For example, when a specific service requires a dedicated slice, the DGL option may be used for this slice to provide high quality and confident predictions.

FIG. 15 illustrates various aspects of utilizing packet data unit (PDU) sessions for DGL transmissions according to some embodiments. The illustrated embodiment includes UE 1502 and network 1504. In various embodiments, UE 1502 and network 1504 may exchange messages 1506a, 1506b (collectively referred to as messages 1506) to establish a PDU sessions. It will be appreciated that one or more components of FIG. 15 may be the same or similar to one or more other components disclosed hereby. For example, UE 1502 may be the same or similar to UE 1102. In another example, network 1504 may be the same or similar to BS 904. Further, aspects discussed with respect to various components in FIG. 15 may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. Embodiments are not limited in this context.

In many embodiments, DGL transmissions may be enabled/disabled per PDU sessions. For example, with a UE based technique, during PDU session establishment, the UE may request the network to enable DGL transmissions. In another example, with an AF based  technique, the AF may inform the PCF (directly or via NEF) about the DGL option, the PCF may inform the SMF about the DGL option such that it can be considered in PDU session configuration.

FIG. 16 illustrates an exemplary flowchart 1600 for DGL transmissions according to some embodiments. Aspects of flowchart 1600 may relate to various embodiments described hereby. In many embodiments, the processes of flow chart flowchart 1600 may be performed by one or more UEs. It will be appreciated that aspects of flow chart 1200 discussed with respect to various components may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. For example, one or more processes described with respect to a UE may be performed by a BS without departing from the scope of this disclosure. Embodiments are not limited in this context.

Flowchart 1600 begins at block 1602. At block 1602, the UE and BS are configured for DGL transmissions. Proceeding to decision block 1604, it may be determined whether predictable data is arriving at the MAC buffer. For example, prediction accuracy may be utilized to determine whether predictable data is arriving. If predictable data is not arriving, the flowchart 1600 may wait until predictable data is arriving. If predictable data is arriving, the ML model may be activated at block 1606. At block 1608, a MAC CE may be sent to the BS to activate the complimentary model at the BS.

At block 1610, data may be received at the MAC buffer and, at block 1612, the next PRBs may be predicted. Proceeding to block, decision block 1614 it may be determined whether the predicted data has arrived in the buffer. If the data has arrived, the data and a modified BSR (e.g., with interpacket arrival time, etc. ) may be transmitted using the predicted resources. However, if the data has not arrived, data from another buffer (e.g., lower priority) and/or a modified BSR may be transmitted in the predicted resources.

Referring to block 1620, the prediction accuracy may be monitored, such as based on blocks 1610, 1612, 1614. At decision block 1622, if fallback conditions are not met (e.g., prediction accuracy above a threshold) , the flowchart 1600 may return to block 1610. However, if fallback conditions are met (e.g., prediction accuracy falls below a threshold) , the ML model may be deactivated at block 1624 and a MAC CE may be sent to the BS to deactivate the model at the BS. After model deactivation, the flowchart 1600 may return to decision block 1604.

FIG. 17 illustrates an exemplary flowchart 1700 for DGL transmissions according to some embodiments. Aspects of flowchart 1700 may relate to various embodiments described  hereby. In many embodiments, the processes of flow chart flowchart 1700 may be performed by one or more BSs. It will be appreciated that aspects of flowchart 1700 discussed with respect to various components may be implemented by one or more other components from one or more other embodiments without departing from the scope of this disclosure. For example, one or more processes described with respect to a BS may be performed by a UE without departing from the scope of this disclosure. Embodiments are not limited in this context.

Flowchart 1700 begins at block 1702. At block 1702, the ML model may be activated in response to a MAC CE with indication from the UE. At block 1704, the BS may receive data in an uplink wireless transmission from the UE (e.g., modified BSR plus data packet) . Proceeding to block 1706, the next PRBs may be predicted, such as based on the received data. At block 1708, the model accuracy may be monitored. Continuing to decision block 1710, based on the monitored accuracy, it may be determined if the conditions for fallback have been met. If the conditions for fallback have been met, the ML model may be deactivated at the BS and a DCI with indication to deactivate the complimentary model may be sent to the UE at block 1712. However, if the conditions for fallback have not been met, the flowchart 1700 may return to block 1702.

FIG. 18 illustrates a logic flow 1800 of an exemplary technique associated with DGL transmissions according to some embodiments. In some embodiments, the logic flow 1800 may be performed by a UE. Aspects of Logic flow 1800 may relate to various embodiments described hereby. Logic flow 1800 may begin at block 1802. Block 1802 may include monitoring an inter-packet arrival time of data packets at a buffer. For example, buffer monitor 712 may monitor inter-packet arrival time of packets 710 in buffer 708.

At block 1804, a projected resource demand for an uplink wireless transmission may be determined. Further, the projected resource demand may be determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs. For example, ML model 716 may determine the projected resource demand (e.g., packet size and/or arrival time for packet 710b) for an uplink wireless transmission. Further, the ML model 716 may be trained, such as by model trainer 722, based on historical resource demands for uplink wireless communications by UE 702.

Proceeding to block 1806, arrival, at the buffer, of a data packet corresponding to the projected resource demand may be identified. For example, arrival of packet 710b in buffer 708 corresponding to the projected resource demand may be identified by buffer monitor 712.  Continuing to block 1808, the data packet may be transmitted with a BSR report to a BS according to the projected resource demand. Further, the BSR may include a last interpacket arrival time. For example, packet 710b may be transmitted with a modified BSR including the interpacket arrival time between packet 710a and packet 710b to BS 704.

FIG. 19 illustrates a logic flow 1900 of an exemplary technique associated with DGL transmissions according to some embodiments. In some embodiments, the logic flow 1900 may be performed by a BS. Aspects of logic flow 1900 may relate to various embodiments described hereby. Logic flow 1900 may begin at block 1902. Block 1902 may include receiving, from a user equipment, a first uplink wireless transmission including an inter-packet arrival time between arrival of a first data packet in a buffer of the UE and arrival of a second data packet in the buffer of the UE. For example, BS 704 may receive, from UE 702, an uplink wireless transmission including an inter-packet arrival time between packet 710a and packet 710b in buffer 708 of UE 702.

Continuing to block 1904, a projected resource demand for a second uplink wireless transmission including a third data packet may be determined based on the interpacket arrival time. Further, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs. For example, BS 704 may determine a projected resource demand (e.g., predicted packet size and packet arrival time) for a second uplink wireless transmission including packet 710c based on the interpacket arrival time between packet 710a and packet 710b (which have previously been transmitted to BS 704 from buffer 708 in this example) . Further, BS 704 may determine the projected resource demand using ML model 726, which may be trained on historical resource demands for uplink wireless communications by UE 702.

At block 1906, the second uplink wireless transmission including the third data packet may be received based on the projected resource demand determined for the second uplink wireless transmission including the third data packet. For example, UE 702 may transmit a modified BSR and packet 710c to BS 704 that the BS 704 receives based on the projected resource demand (e.g., predicted packet size and packet arrival time) .

Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus, processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine  that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract” ) instructions into processor specific instructions (e.g., an abstract execution environment such as a “virtual machine” (e.g., a Java Virtual Machine) , an interpreter, a Common Language Runtime, a high-level language virtual machine, etc. ) , and/or, electronic circuitry disposed on a semiconductor chip (e.g., “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code.

The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs) , RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

A machine readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer) . For example, a machine readable medium includes read only memory ( “ROM” ) ; random access memory ( “RAM” ) ; magnetic disk storage media; optical storage media; flash memory devices; et cetera.

An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other) ) , optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection) ) .

There are a number of example embodiments described herein.

Example 1 is a method for wireless communication by a user equipment (UE) , the method comprising: monitoring an inter-packet arrival time of data packets at a buffer; determining a projected resource demand for an uplink wireless transmission, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs; identifying arrival, at the buffer, of a data packet corresponding to the projected resource demand; and transmitting the data packet with a buffer status report (BSR) to a base station (BS) according to the projected resource demand, wherein the BSR includes a last inter-packet arrival time.

Example 2 is the method of Example 1 that may optionally include that the projected resource demand for the uplink wireless transmission comprises a projected size and a projected arrival time at the buffer of the data packet.

Example 3 is the method of Example 1 that may optionally include that the projected resource demand for the uplink wireless transmission comprises a projected size of the data packet.

Example 4 is the method of Example 1 that may optionally include that the projected resource demand for uplink wireless communications comprises a predicted physical resource block (PRB) allocation.

Example 5 is the method of Example 1 that may optionally include transmitting the data packet with the buffer status report to the BS according to the projected resource demand without receiving a resource grant from the BS.

Example 6 is the method of Example 1 that may optionally include determining the projected resource demand for the uplink wireless transmission based on a dynamic grant-less transmission configuration received from the BS.

Example 7 is the method of Example 6 that may optionally include that the dynamic grant-less transmission configuration includes one or more indications of a duration of dynamic grant-less transmissions, a resource index, a resource pool, and message acknowledgement settings.

Example 8 is the method of Example 6 that may optionally include that the dynamic grant-less transmission configuration is received with one or more of a radio resource control (RRC) configuration message and a downlink control information (DCI) message.

Example 9 is the method of Example 6 that may optionally include receiving the dynamic grant-less transmission configuration in response to transmitting a dynamic grant-less transmission request to the BS.

Example 10 is the method of Example 9 that may optionally include that the dynamic grant-less transmission request includes an identifier of the ML model.

Example 11 is the method of Example 9 that may optionally include that the dynamic grant-less transmission request is transmitted with one or more of a media access control (MAC) control element (CE) message and a BSR message.

Example 12 is the method of Example 1 that may optionally include that the buffer status report includes one or more indications of a prediction error correction term, an updated ML model identifier, an ML model state, and an ML model accuracy.

Example 13 is the method of Example 1 that may optionally include receiving, from the BS, an indication of a configuration of a resource pool; and utilizing at least a portion of the resource pool to transmit the data packet with the BSR to the BS according to the projected resource demand.

Example 14 is the method of Example 13 that may optionally include that the resource pool comprises a frequency domain resource pool.

Example 15 is the method of Example 13 that may optionally include that the resource pool comprises a time domain resource pool.

Example 16 is the method of Example 13 that may optionally include that the indication of the configuration of the resource pool is received in a radio resource control message.

Example 17 is the method of Example 1 that may optionally include receiving, from the BS, an indication of a random offset in time, and wherein the projected resource demand comprises a projected arrival time at the buffer of the data packet configured with the random offset in time.

Example 18 is the method of Example 17 that may optionally include that the random offset in time is a multiple of a transmission time interval.

Example 19 is a user equipment (UE) comprising one or more processors configured to perform the method of any of Examples 1 to 18.

Example 20 is a non-transitory machine-readable medium having executable instructions to cause one or more processing units to perform the method of any of Examples 1 to 18.

Example 21 is a method for wireless communication by a base station (BS) , the method comprising: receiving, from a user equipment (UE) , a first uplink wireless transmission including an inter-packet arrival time between arrival of a first data packet in a buffer of the UE and arrival of a second data packet in the buffer of the UE; determining, based on the inter-packet arrival time, a projected resource demand for a second uplink wireless transmission including a third data packet, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs; and receiving the second uplink wireless transmission including the third data packet based on the projected resource demand determined for the second uplink wireless transmission including the third data packet.

Example 22 is the method of Example 21 that may optionally include that the first uplink wireless transmission includes a first buffer status report (BSR) and the second uplink wireless transmission includes a second (BSR) .

Example 23 is the method of Example 21 that may optionally include that the projected resource demand for the second uplink wireless transmission comprises a projected size and a projected arrival time at the buffer of the data packet.

Example 24 is the method of Example 21 that may optionally include that the projected resource demand for the second uplink wireless transmission comprises a projected size of the data packet.

Example 25 is the method of Example 21 that may optionally include that the projected resource demand for the second uplink wireless communications comprises a predicted physical resource block (PRB) allocation.

Example 26 is the method of Example 21 that may optionally include receiving the third data packet with a buffer status report from the UE according to the projected resource demand without communicating a resource grant to the UE.

Example 27 is the method of Example 21 that may optionally include determining the projected resource demand for the uplink wireless transmission in response to receipt of a dynamic grant-less transmission activation indication received from the UE.

Example 28 is the method of Example 27 that may optionally include that the dynamic grant-less transmission activation indication is received with a buffer status report.

Example 29 is the method of Example 21 that may optionally include determining a dynamic grant-less transmission configuration; and transmitting the dynamic grant-less transmission configuration to the UE.

Example 30 is the method of Example 29 that may optionally include that the dynamic grant-less transmission configuration includes one or more indications of a duration of dynamic grant-less transmissions, a resource index, a resource pool, and message acknowledgement settings.

Example 31 is the method of Example 29 that may optionally include that the dynamic grant-less transmission configuration is transmitted to the UE with one or more of a radio resource control (RRC) configuration message and a downlink control information (DCI) message.

Example 32 is the method of Example 29 that may optionally include transmitting the dynamic grant-less transmission configuration to the UE in response to receiving a dynamic grant-less transmission request from the BS.

Example 33 is the method of Example 32 that may optionally include that the dynamic grant-less transmission request includes an identifier of the ML model.

Example 34 is the method of Example 32 that may optionally include that the dynamic grant-less transmission request is received with one or more of a media access control (MAC) control element (CE) message and a BSR message.

Example 35 is the method of Example 21 that may optionally include determining a dynamic grant-less transmission configuration; and utilizing the dynamic grant-less transmission configuration to receive the second uplink wireless transmission including the third data packet based on the projected resource demand.

Example 36 is the method of Example 21 that may optionally include that the second uplink wireless communication includes one or more indications of a prediction error correction term, an updated ML model identifier, an ML model state, and an ML model accuracy.

Example 37 is the method of Example 21 that may optionally include determining a configuration of a resource pool; and transmitting an indication of the configuration of the resource pool to the UE.

Example 38 is the method of Example 37 that may optionally include that the resource pool comprises a frequency domain resource pool.

Example 39 is the method of Example 37 that may optionally include that the resource pool comprises a time domain resource pool.

Example 40 is the method of Example 37 that may optionally include that the indication of the configuration of the resource pool is transmitted in a radio resource control message.

Example 41 is the method of Example 21 that may optionally include determining a random offset in time for the UE, and wherein the projected resource demand comprises a projected arrival time at the buffer of the data packet configured with the random offset in time.

Example 42 is the method of Example 41 that may optionally include that the random offset in time is a multiple of a transmission time interval.

Example 43 is a user equipment (UE) comprising one or more processors configured to perform the method of any of Examples 21 to 42.

Example 44 is a non-transitory machine-readable medium having executable instructions to cause one or more processing units to perform the method of any of Examples 21 to 42.

The preceding detailed descriptions are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the tools used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be kept in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “selecting, ” “determining, ” “receiving, ” “forming, ” “grouping, ” “aggregating, ” “generating, ” “removing, ” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the operations described. The required structure for a variety of these systems will be evident from the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.

It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

The foregoing discussion merely describes some exemplary embodiments of the present disclosure. One skilled in the art will readily recognize from such discussion, the accompanying drawings and the claims that various modifications can be made without departing from the spirit and scope of the disclosure.

Claims (30)

1. A method for wireless communication by a user equipment (UE) , the method comprising:

   monitoring an inter-packet arrival time of data packets at a buffer;

   determining a projected resource demand for an uplink wireless transmission, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs;

   identifying arrival, at the buffer, of a data packet corresponding to the projected resource demand; and

   transmitting the data packet with a buffer status report (BSR) to a base station (BS) according to the projected resource demand, wherein the BSR includes a last inter-packet arrival time.
2. The method of claim 1, wherein the projected resource demand for the uplink wireless transmission comprises a projected size and a projected arrival time at the buffer of the data packet.
3. The method of claim 1, wherein the projected resource demand for the uplink wireless transmission comprises a projected size of the data packet.
4. The method of claim 1, wherein the projected resource demand for uplink wireless communications comprises a predicted physical resource block (PRB) allocation.
5. The method of claim 1, further comprising transmitting the data packet with the buffer status report to the BS according to the projected resource demand without receiving a resource grant from the BS.
6. The method of claim 1, further comprising determining the projected resource demand for the uplink wireless transmission based on a dynamic grant-less transmission configuration received from the BS.
7. The method of claim 6, wherein the dynamic grant-less transmission configuration includes one or more indications of a duration of dynamic grant-less transmissions, a resource index, a resource pool, and message acknowledgement settings.
8. The method of claim 6, wherein the dynamic grant-less transmission configuration is received with one or more of a radio resource control (RRC) configuration message and a downlink control information (DCI) message.
9. The method of claim 6, further comprising receiving the dynamic grant-less transmission configuration in response to transmitting a dynamic grant-less transmission request to the BS.
10. The method of claim 9, wherein the dynamic grant-less transmission request includes an identifier of the ML model.
11. A user equipment (UE) comprising one or more processors configured to perform operations comprising:

    monitoring an inter-packet arrival time of data packets at a buffer;

    determining a projected resource demand for an uplink wireless transmission, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs;

    identifying arrival, at the buffer, of a data packet corresponding to the projected resource demand; and

    transmitting the data packet with a buffer status report (BSR) to a base station (BS) according to the projected resource demand, wherein the BSR includes a last inter-packet arrival time.
12. The UE of claim 11, wherein the projected resource demand for the uplink wireless transmission comprises a projected size and a projected arrival time at the buffer of the data packet.
13. The UE of claim 11, wherein the projected resource demand for the uplink wireless transmission comprises a projected size of the data packet.
14. The UE of claim 11, wherein the projected resource demand for uplink wireless communications comprises a predicted physical resource block (PRB) allocation.
15. The UE of claim 11, wherein the buffer status report includes one or more indications of a prediction error correction term, an updated ML model identifier, an ML model state, and an ML model accuracy.
16. The UE of claim 11, further comprising:

    receiving, from the BS, an indication of a configuration of a resource pool; and

    utilizing at least a portion of the resource pool to transmit the data packet with the BSR to the BS according to the projected resource demand.
17. A non-transitory machine-readable medium having executable instructions to cause one or more processing units to perform a method, the method comprising:

    monitoring an inter-packet arrival time of data packets at a buffer;

    determining a projected resource demand for an uplink wireless transmission, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs;

    identifying arrival, at the buffer, of a data packet corresponding to the projected resource demand; and

    transmitting the data packet with a buffer status report (BSR) to a base station (BS) according to the projected resource demand, wherein the BSR includes a last inter-packet arrival time.
18. The non-transitory machine-readable medium of claim 17, wherein the projected resource demand for the uplink wireless transmission comprises a projected size of the data packet.
19. The non-transitory machine-readable medium of claim 17, further comprising receiving, from the BS, an indication of a random offset in time, and wherein the projected resource demand comprises a projected arrival time at the buffer of the data packet configured with the random offset in time.
20. The non-transitory machine-readable medium of claim 19, wherein the random offset in time is a multiple of a transmission time interval.
21. A method for wireless communication by a base station (BS) , the method comprising:

    receiving, from a user equipment (UE) , a first uplink wireless transmission including an inter-packet arrival time between arrival of a first data packet in a buffer of the UE and arrival of a second data packet in the buffer of the UE;

    determining, based on the inter-packet arrival time, a projected resource demand for a second uplink wireless transmission including a third data packet, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs; and

    receiving the second uplink wireless transmission including the third data packet based on the projected resource demand determined for the second uplink wireless transmission including the third data packet.
22. The method of claim 21, wherein the first uplink wireless transmission includes a first buffer status report (BSR) and the second uplink wireless transmission includes a second (BSR) .
23. The method of claim 21, wherein the projected resource demand for the second uplink wireless transmission comprises a projected size and a projected arrival time at the buffer of the data packet.
24. The method of claim 21, wherein the projected resource demand for the second uplink wireless communications comprises a predicted physical resource block (PRB) allocation.
25. The method of claim 21, further comprising receiving the third data packet with a buffer status report from the UE according to the projected resource demand without communicating a resource grant to the UE.
26. A network comprising one or more processors configured to perform operations comprising:

    receiving, from a user equipment (UE) , a first uplink wireless transmission including an inter-packet arrival time between arrival of a first data packet in a buffer of the UE and arrival of a second data packet in the buffer of the UE;

    determining, based on the inter-packet arrival time, a projected resource demand for a second uplink wireless transmission including a third data packet, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs; and

    receiving the second uplink wireless transmission including the third data packet based on the projected resource demand determined for the second uplink wireless transmission including the third data packet.
27. The network of claim 26, further comprising determining the projected resource demand for the uplink wireless transmission in response to receipt of a dynamic grant-less transmission activation indication received from the UE.
28. The network of claim 27, wherein the dynamic grant-less transmission activation indication is received with a buffer status report.
29. A non-transitory machine-readable medium having executable instructions to cause one or more processing units to perform a method, the method comprising:

    receiving, from a user equipment (UE) , a first uplink wireless transmission including an inter-packet arrival time between arrival of a first data packet in a buffer of the UE and arrival of a second data packet in the buffer of the UE;

    determining, based on the inter-packet arrival time, a projected resource demand for a second uplink wireless transmission including a third data packet, the projected resource demand determined with a machine learning (ML) model trained on historical resource demands for uplink wireless communications by one or more UEs; and

    receiving the second uplink wireless transmission including the third data packet based on the projected resource demand determined for the second uplink wireless transmission including the third data packet.
30. The non-transitory machine-readable medium of claim 29, the method further comprising:

    determining a dynamic grant-less transmission configuration; and

    transmitting the dynamic grant-less transmission configuration to the UE, wherein the dynamic grant-less transmission configuration includes one or more indications of a duration of dynamic grant-less transmissions, a resource index, a resource pool, and message acknowledgement settings.