Techniques to support predictive scheduling for low latency communications
By using predictive scheduling technology, which utilizes machine learning models and artificial intelligence to predict resource demand and optimize resource allocation, the problem of low resource allocation efficiency in existing technologies is solved, and efficient resource management for low-latency communication is achieved.
Patent Information
- Application Number
- CN202480046546.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-07-13
- Filing Date
- 2024-07-12
- Publication Date
- 2026-02-13
AI Technical Summary
Existing technologies cannot effectively adapt to dynamically changing business needs, resulting in inefficient resource allocation and increased latency in low-latency communication, which affects system availability and user experience.
Predictive scheduling technology is adopted, which uses machine learning models to predict the resource requirements of uplink wireless communication. Resources are actively requested through scheduling requests and buffer status reports. Combined with conditional multiple granting and artificial intelligence/machine learning to predict data packet size and arrival time, resource allocation is optimized.
It improved the resource utilization of the telecommunications system, reduced the amount of buffer data and uplink latency, and improved the user experience and system availability.
Smart Images

Figure CN121533124A_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 513,416, filed July 13, 2023, entitled “Techniques to Support Predictive Scheduling for Low Latency Communications.” The content of this U.S. Provisional Application is incorporated herein by reference in its entirety. TECHNICAL FIELD
[0003] The present disclosure relates generally to wireless technology, and more particularly, yet to techniques to support predictive scheduling for low latency communications. BACKGROUND
[0004] In telecommunications, 5G is the fifth generation technology standard for wideband cellular networks. Like its predecessors, a 5G network is a cellular network in which service areas are divided into small geographic regions called network cells (or cells). The 3rd Generation Partnership Project (3GPP) is an industry alliance that sets standards for 5G. One of the technologies supported by 5G includes low latency communications, such as Ultra-Reliable Low-Latency Communications (URLLC). Generally, URLLC refers to the use of a network for mission-critical applications that require uninterrupted and robust exchange of data. For example, mission-critical applications can include one or more of the following: public safety, remote diagnostics / surgery, emergency response, autonomous driving, industrial automation, and smart energy / smart grid. Generally, URLLC requires an availability of greater than 99.999% and an end-to-end system latency of no more than 5 milliseconds. Other uses of low latency communications can include extended reality, cloud gaming, streaming, and haptic communications. SUMMARY
[0005] Processes, machines, and articles of manufacture for supporting predictive scheduling for low latency communications are described. It should be understood that the implementations can be combined in any number of ways without departing from the scope of the present disclosure.
[0006] Implementations can include determining a projected resource demand for uplink wireless communications, the projected resource demand for uplink wireless communications being determined with a machine learning (ML) model trained according to historical resource demands for uplink wireless communications by one or more UEs; sending, to a base station (BS), a resource request message including an indication of the projected resource demand for uplink wireless communications; and identifying a resource grant including granted resources corresponding to the projected resource demand for uplink wireless communications.
[0007] Implementations can include identifying historical resource needs for uplink wireless communications of a user equipment (UE), training a machine learning model to determine projected resource needs for uplink wireless communications of the UE, sending the ML model to the UE, identifying an indication of the projected resource needs for uplink wireless communications of the UE in a resource request message, and granting resources to the UE based on the projected resource needs for wireless communications of the UE.
[0008] Other processes, machines, and articles of manufacture, and / or the like, are also described, which can be combined in any number of ways, such as with embodiments of the summary, without departing from the scope of the disclosure. BRIEF DESCRIPTION OF DRAWINGS
[0009] The disclosure is exemplified by way of example, and is not limited to the graphic representations of the drawings, in which like reference numerals indicate like elements. To readily identify the discussion of any particular element or action, one or more of the most significant digits in the reference number are to the figure number in which the element is first introduced.
[0010] Figure 1 An exemplary wireless communication system according to some embodiments is exemplified.
[0011] Figure 2 A base station (BS) in communication with a user equipment (UE) device according to some embodiments is exemplified.
[0012] Figure 3 An exemplary block diagram of a UE according to some embodiments is exemplified.
[0013] Figure 4 An exemplary block diagram of a BS according to some embodiments is exemplified.
[0014] Figure 5 An exemplary block diagram of cellular communication circuitry according to some embodiments is exemplified.
[0015] Figure 6 An exemplary block diagram of a network message according to some embodiments is exemplified.
[0016] Figure 7 An exemplary block diagram of a UE in conjunction with a BS according to some embodiments is exemplified.
[0017] Figure 8 A process diagram for predictive scheduling according to some embodiments is exemplified.
[0018] Figure 9 Various aspects of predictive scheduling according to some embodiments are exemplified.
[0019] Figure 10Example operational configurations for predictive scheduling are illustrated in accordance with some embodiments.
[0020] Figure 11A and Figure 11B Example operational configurations for predictive scheduling are illustrated in accordance with some embodiments.
[0021] Figure 12 Example flow diagrams for predictive scheduling are illustrated in accordance with some embodiments.
[0022] Figure 13 Process diagrams for predictive scheduling are illustrated in accordance with some embodiments.
[0023] Figure 14 Logical flows of example techniques for predictive scheduling at a UE are illustrated in accordance with some embodiments.
[0024] Figure 15 Logical flows of example techniques for predictive scheduling at a UE are illustrated in accordance with some embodiments. DETAILED DESCRIPTION
[0025] In general, the present disclosure describes techniques that support predictive scheduling for low latency communications. More specifically, embodiments relate to reducing scheduling latency with projected resource needs. In the following description, numerous specific details are set forth to provide a 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 can be practiced without some or all of these specific details. In other instances, well known components, structures, and techniques have not been shown to avoid obscuring the understanding of this description.
[0026] Reference throughout this 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 present disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
[0027] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, can be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” can be used to indicate that two or more elements, which can or can not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” can be used to indicate the establishment of communication between two or more elements that are coupled with each other.
[0028] The processes depicted in the following figures are performed by processing logic that comprises hardware (e.g. circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computing device or a dedicated machine), or a combination of both. Although the processes are described in a particular sequential order, some of which can be performed concurrently, it is understood that other operations can be performed in an order other than that described herein. Moreover, some operations can be performed in parallel rather than sequentially.
[0029] The terms "server," "client," and "device" are intended to refer generally to data processing systems, rather than specifically to the particular form factors of servers, clients, and / or devices.
[0030] Existing techniques for low latency communications are unable to provide the ability to adapt to dynamically changing traffic. For example, scheduling of resources is performed in a reactive manner, i.e., waiting until a data packet is in a buffer before requesting resources for transmitting the data packet. Uplink communications for different packet data unit sizes are often required for low latency communications applications and can result in jitter, further increasing complexity. In addition, uplink communications can be periodic, quasi-periodic, or aperiodic. For applications such as gaming, video streaming, autonomous driving, etc., uplink communications with low latency can be required. However, granting uplink resources for such applications with existing techniques (e.g., semi-persistent scheduling, grant-free access, or proactive grant) results in many inefficiencies, such as excessive resource allocation, poor resource utilization, excessive overhead, and excessive latency. These limitations can greatly reduce the availability and applicability of telecommunication systems, resulting in poor user experience and limited and inefficient systems, devices, and techniques.
[0031] Accordingly, many embodiments disclosed herein provide resource-efficient techniques that adapt to dynamically changing traffic using predictive scheduling. Various embodiments can anticipate resource needs and request resources based on the anticipated resource needs. For example, embodiments can utilize scheduling requests (SRs) and / or buffer status reports (BSRs) to proactively request resources from a base station based on predicted traffic, such as predicted traffic at an expected uplink resource grant. In some embodiments, conditional multiple grants can be utilized. For example, multiple grants can be configured at the same time, and only if a UE cannot fully utilize a previous grant, the UE can use a later grant. In many embodiments, only one of the multiple grants can be used for an uplink transmission corresponding to an anticipated resource need, and other grants of the multiple grants prior to the uplink transmission corresponding to the anticipated resource need can be used for transmitting other data, such as from other buffers. In several embodiments, artificial intelligence and / or machine learning can be utilized to predict (or anticipate) future data packet sizes and packet arrival times. In several such embodiments, these predictions can be used to request resources for data packets before the data packets arrive at a buffer.
[0032] In these and other ways, the components / techniques described herein can provide numerous technical advantages. For example, the computer-based techniques of the present disclosure improve the functionality of telecommunications systems as compared to conventional approaches because these techniques enable predictive scheduling that can improve accessibility, reduce latency, reduce overhead, and provide extended capabilities for telecommunications systems as compared to conventional approaches. In many embodiments, predictive scheduling can reduce the average amount of data in a buffer and / or reduce average uplink latency. Moreover, the embodiments disclosed herein can be practically used to improve the functionality of computers and / or improve various technical fields, including telecommunications, computer networking, scheduling, resource utilization, low-latency communications, URLLC, artificial intelligence, machine learning, and / or user experience.
[0033] It should be appreciated that various aspects of the telecommunications networks, capabilities, protocols, formats, and procedures related to the techniques described herein and the terminology cited herein can be found in 3GPP Technical Specifications (TSs), such as TS 38.300 and TS 38.321.
[0034] Figure 1 A simplified exemplary wireless communication system is illustrated in accordance with some embodiments. Note that the system of Figure 1 The system of FIG. 1 is merely one example of possible systems, and features of the present disclosure can be implemented in any of various systems as desired.
[0035] As shown, the example wireless communication system includes a base station 102A that communicates with one or more user devices 106A, user device 106B through user device 106N, etc. over a transmission medium. Each user device can 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.
[0036] The base station (BS) 102A can be a base transceiver station (BTS) or cell site (“cellular base station”), and can include hardware that enables it to implement wireless communications with the UEs 106A through 106N.
[0037] The communication area (or coverage area) of a base station can be referred to as a “cell.” The base station 102A and UEs 106 can be configured to communicate
[0038] As shown, the base station 102A can also be equipped to communicate with a network 100 (e.g., with a core network of a cellular service provider, a telecommunications network such as a public switched telephone network (PSTN), and / or the Internet, among various possibilities). Thus, the base station 102A can facilitate communication between and among user devices and / or between and among user devices and the network 100. Specifically, the cellular base station 102A can 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 can be used to collectively refer to one or more devices and components that form a telecommunications network. For example, a reference to the network transmitting data to / from a UE can refer to one or more portions of a core network of a cellular service provider and / or one or more base stations. In some such examples, data to be transmitted to a UE can be determined by a core network component and then relayed to the UE via a base station. In other such examples, data to be transmitted to a UE can be determined by and transmitted to the UE by a base station.
[0039] The base station 102A and other similar base stations such as the base stations 102B... 102N, operating according to the same or different cellular communication standards, can thus provide a network of cells that can provide continuous or approximately continuous overlapping service to the UEs 106A-N and similar devices via one or more cellular communication standards over a geographic area.
[0040] Thus, although the base station 102A can act as a "serving cell" for the UEs 106A-N as exemplified in Figure 1 each UE 106 can also be capable of receiving signals from one or more other cells (which can be provided by the base stations 102B-N and / or any other base stations), which can be referred to as "neighboring cells," that can be within its range of communication (and possibly at various distances therefrom). Such cells can also enable communication between user equipment and / or user equipment and the network 100. Such cells can include "macro" cells, "micro" cells, "pico" cells, and / or any of various other granularities of service area sizes. For example, the base stations 102A-B can be macro cells, while the base station 102N can be a micro cell. Other configurations are also possible. Figure 1
[0041] In some embodiments, the base station 102A can be a next generation base station, e.g., a 5G New Radio (5G NR) base station or "gNB." In some embodiments, the gNB can be connected to a legacy evolved packet core (EPC) network and / or to an NR core (NRC) network. Further, a gNB cell can include one or more transition and reception points (TRPs). Further, a UE capable of operating according to 5G NR can be connected to one or more TRPs within one or more gNBs.
[0042] It is noted that the UE 106 can be capable of communicating using multiple wireless communication standards. For example, the UE 106 can be configured to communicate using wireless networking (e.g., Wi-Fi) and / or peer-to-peer wireless communication protocols in addition to at least one cellular communication protocol (e.g., GSM, UMTS (associated with, for example, a WCDMA or TD-SCDMA air interface), LTE, LTE-A, 5G NR, 6G, HSPA, 3GPP2 CDMA2000 (e.g., lxRTT, lxEV-DO, HRPD, eHRPD), etc.). If desired, the UE 106 can also or alternatively be configured to communicate using one or more global navigation satellite systems (GNSS, such as GPS or GLONASS), one or more mobile television broadcasting standards (such as ATSC-M / H or DVB-H), and / or any other wireless communication protocol. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.
[0043] Figure 2 A user equipment 106 (e.g., one of devices 106A-106N) that communicates with base stations 102 is illustrated in accordance with some embodiments. The UE 106 can be a device with cellular communication capability such as a mobile phone, a handheld device, a computer or a tablet computer, or virtually any type of wireless device.
[0044] The UE 106 can include a processor that is configured to execute program instructions stored in memory. The UE 106 can perform any of the method embodiments described herein by executing such stored instructions. Alternatively, or in addition, the UE 106 can include programmable hardware elements such as a field programmable gate array (FPGA) configured to perform any of the method embodiments described herein, or any portion of any of the method embodiments described herein.
[0045] The UE 106 can include one or more antennas to communicate using one or more wireless communication protocols or technologies. In some embodiments, the UE 106 can be configured to communicate using, for example, 5G NR, CDMA2000 (lxRTT / lxEV-DO / HRPD / eHRPD), 6G, or LTE and GSM, or LTE using a single shared radio. The shared radio can be coupled to a single antenna, or can be coupled to multiple antennas (e.g., for MIMO) for performing wireless communication. Generally, the radio can 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 can implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE 106 can share one or more parts of a receive and / or transmit chain between multiple wireless communication technologies, such as those discussed above.
[0046] In some embodiments, the UE 106 can include separate transmit and / or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol configured to communicate therewith. As another possibility, the UE 106 can include one or more radios shared between multiple wireless communication protocols, along with one or more radios used exclusively by a single wireless communication protocol. For example, the UE 106 can include a shared radio for communicating using either of LTE or 5G NR (or LTE or lxRTT, or LTE or GSM, or 6G), and separate radios for communicating using each of Wi-Fi and Bluetooth. Other configurations are also possible.
[0047] Figure 3 An example simplified block diagram of a communication device 106 according to some embodiments is illustrated. Note that Figure 3The block diagram of the communication device is merely one example of a possible communication device. The communication device 106 can 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., laptop, notebook, or portable computing device), a tablet, and / or combinations of devices, among other devices, according to embodiments. As shown, the communication device 106 can include a set of components 300 configured to perform core functionality. For example, the set of components can be implemented as a system on a chip (SOC), which can include portions for various purposes. Alternatively, the set of components 300 can be implemented to be separate or integrated components for various purposes. The set of components 300 can be coupled (e.g., in communication) with various other circuitry of the communication device 106.
[0048] For example, the communication device 106 can include various types of memory (e.g., including NAND flash 310), input / output interfaces such as a connector I / F 320 (e.g., for connecting to a computer system; a dock; a charging station; an input device, such as a microphone, camera, keyboard; an output device, such as a speaker; etc.), a display 360 that can be integrated with or external to the communication device 106, and cellular communication circuitry 330, such as for 5G NR, LTE, GSM, and so on, and short-to-medium range wireless communication circuitry 329 (e.g., Bluetooth ™ and WLAN circuitry). In some embodiments, the communication device 106 can include wired communication circuitry (not shown), such as a network interface card (e.g., for Ethernet).
[0049] The cellular communication circuitry 330 can be (e.g., communicatively; directly or indirectly) coupled to one or more antennas, such as the antennas 335 and 336 shown. The short-to-medium range wireless communication circuitry 329 can also be (e.g., communicatively; directly or indirectly) coupled to one or more antennas, such as the antennas 337 and 338 shown. Alternatively, the short-to-medium range wireless communication circuitry 329 can also be (e.g., communicatively; directly or indirectly) coupled to the antennas 335 and 336, in addition to or in alternative to being coupled to the antennas 337 and 338. The short-to-medium range wireless communication circuitry 329 and / or the cellular communication circuitry 330 can include multiple receive and / or transmit chains for receiving and / or transmitting multiple spatial streams, such as in a multiple-input multiple-output (MIMO) configuration.
[0050] In some embodiments, as described further below, cellular communication circuitry 330 can include dedicated receive chains (including and / or coupled to (e.g., communicatively; directly or indirectly) dedicated processors and / or radio components) for multiple radio access technologies (RATs) (e.g., a first receive chain for LTE and a second receive chain for 5G NR). Further, in some embodiments, cellular communication circuitry 330 can include a single transmit chain that can be switched between radio components dedicated to a particular RAT. For example, a first radio component can be dedicated to a first RAT, such as LTE, and can communicate with a dedicated receive chain as well as a transmit chain shared with additional radio components, such as a second radio component that can be dedicated to a second RAT (e.g., 5G NR) and can communicate with a dedicated receive chain as well as the shared transmit chain.
[0051] Communication device 106 can also include one or more user interface elements and / or be configured for use with one or more user interface elements. User interface elements can include any of a variety of elements, such as a display 360 (which can be a touch screen display), a keyboard (which can be a discrete keyboard or can be implemented as part of a touch screen display), a mouse, a microphone, and / or a speaker, one or more cameras, one or more buttons, and / or any of a variety of other elements capable of providing information to a user and / or receiving or interpreting user input.
[0052] Communication device 106 can also include one or more smart cards 345 having SIM (Subscriber Identity Module) functionality, such as one or more UICCs (Universal Integrated Circuit Cards) 345.
[0053] As shown, SOC 300 can include a processor 302, which can execute program instructions for communication device 106, and a display circuit 304, which can perform graphics processing and provide display signals to display 360. Processor 302 can also be coupled to a memory management unit (MMU) 340, which can be configured to receive addresses from processor 302 and translate those addresses to locations in memory (e.g., memory 306, read only memory (ROM) 350, NAND flash memory 310) or to other circuits or devices (such as display circuit 304, short-range wireless communication circuitry 229, cellular communication circuitry 330, connector I / F 320, and / or display 360). MMU 340 can be configured to perform memory protection and page table translation or set up. In some embodiments, MMU 340 can be included as part of processor 302.
[0054] As noted above, the communication device 106 can be configured to communicate using wireless and / or wired communication circuitry. The communication device 106 can be configured to transmit a request to attach to a first network node operating according to a first RAT (e.g., 5G NR, 4G LTE, Bluetooth, Wi-Fi, etc.) and transmit an indication that the wireless device is capable of maintaining substantially concurrent connectivity with the first network node and a second network node operating according to a second RAT (e.g., 5G NR, 4G LTE, Bluetooth, Wi-Fi, etc.). The wireless device can also be configured to transmit a request to attach to the second network node. The request can include an indication that the wireless device is capable of maintaining substantially concurrent connectivity with the first network node and the second network node. Further, the wireless device can be configured to receive an indication that dual connectivity with the first network node and the second network node has been established.
[0055] As described herein, the communication device 106 can include hardware and software components for implementing the above-described features for supporting predictive scheduling. For example, the processor 302 of the communication device 106 can 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), the processor 302 can 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 can be configured, in conjunction with one or more of the other components 300, 304, 306, 310, 320, 329, 330, 340, 345, 350, 360, to implement part or all of the features described herein.
[0056] Further, as described herein, the processor 302 can include one or more processing elements. Thus, the processor 302 can include one or more integrated circuits (ICs) that are configured to perform the functions of the processor 302. In addition, each integrated circuit can include circuitry (e.g., a first circuit, a second circuit, etc.) that is configured to perform the functions of the processor 302.
[0057] Furthermore, as described herein, both the cellular communication circuit 330 and the short-range wireless communication circuit 329 may include one or more processing elements. In other words, one or more processing elements may be included in the cellular communication circuit 330, and similarly, one or more processing elements may be included in the short-range wireless communication circuit 329. Therefore, the cellular communication circuit 330 may include one or more integrated circuits (ICs) configured to perform the functions of the cellular communication circuit 330. Furthermore, each integrated circuit may include circuitry (e.g., a first circuit, a second circuit, etc.) configured to perform the functions of the cellular communication circuit 330. Similarly, the short-range wireless communication circuit 329 may include one or more ICs configured to perform the functions of the short-range wireless communication circuit 329. Furthermore, each integrated circuit may include circuitry (e.g., a first circuit, a second circuit, etc.) configured to perform the functions of the short-range wireless communication circuit 329.
[0058] Figure 4 An exemplary block diagram of a base station 102 according to some implementation schemes is shown. It should be noted that... Figure 4 The base station shown is merely one example of a possible base station. As illustrated, base station 102 may include processor 404, which executes program instructions for base station 102. Processor 404 may also be coupled to memory management unit (MMU) 440, which may be configured to receive addresses from processor 404 and translate these addresses into locations in memory (e.g., memory 460 and read-only memory (ROM) 450), or to other circuitry or devices.
[0059] Base station 102 may include at least one network port 470. Network port 470 may be configured to couple to a telephone network and provide access rights as described above. Figure 1 and Figure 2 The telephone network described herein includes multiple devices such as UE device 106.
[0060] Network port 470 (or an additional network port) may also be configured, or alternatively configured, to couple to a cellular network, such as the core network of a cellular service provider. The core network may provide mobility-related services and / or other services to multiple devices, such as UE device 106. In some cases, network port 470 may be coupled to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., in other UE devices served by a cellular service provider).
[0061] In some implementations, the base station 102 can be a next generation base station, e.g., a 5G New Radio (5G NR) base station, or “gNB.” In such implementations, the base station 102 can be connected to a legacy evolved packet core (EPC) network and / or to an NR core (NRC) network. Moreover, the base station 102 can be considered a 5G NR cell, and can include one or more transition and reception points (TRPs). Further, a UE capable of operating according to 5G NR can be connected to one or more TRPs within one or more gNBs.
[0062] The base station 102 can include at least one antenna 434, and can include multiple antennas, such as an antenna array (see, e.g., FIG. 4 Figure 12 ). The at least one antenna 434 can be configured to operate as a wireless transceiver, and can also be configured to communicate with UE devices 106 via the radio 430. The antenna 434 communicates with the radio 430 via a communication chain 432. The communication chain 432 can be a receive chain, a transmit chain, or both. The radio 430 can be configured to communicate via a variety of wireless communication standards, including but not limited to 5G NR, LTE, LTE-A, GSM, UMTS, CDMA2000, Wi-Fi, etc.
[0063] The base station 102 can be configured to communicate wirelessly using multiple wireless communication standards. In some instances, the base station 102 can include multiple radios that can enable the base station 102 to communicate according to multiple wireless communication technologies. For example, as one possibility, the base station 102 can include an LTE radio for performing communications according to LTE and a 5G NR radio for performing communications according to 5G NR. In this case, the base station 102 can be capable of operating as both an LTE base station and a 5G NR base station. As another possibility, the base station 102 can include a multi-mode radio capable of performing communications according to any of a plurality of wireless communication technologies, e.g., 5G NR and Wi-Fi, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, etc.
[0064] As further described later herein, the BS 102 can include hardware and software components for implementing or supporting the implementations described herein. The processor 404 of the base station 102 can be configured to implement or support implementing parts of 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 can 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 additionally) the processor 404 of the BS 102, in conjunction with one or more of the other components 430, 432, 434, 440, 450, 460, 470 can be configured to implement or support implementing parts or all of the features described herein.
[0065] Further, as described herein, the processor 404 can be composed of one or more processing elements. In other words, one or more processing elements can be included in the processor 404. Thus, the processor 404 can include one or more integrated circuits (ICs) that are configured to perform the functions of the processor 404. Further, each integrated circuit can include circuitry (e.g., first circuitry, second circuitry, etc.) configured to perform the functions of the processor 404.
[0066] Further, as described herein, the radio 430 can be composed of one or more processing elements. In other words, one or more processing elements can be included in the radio 430. Thus, the radio 430 can include one or more integrated circuits (ICs) that are configured to perform the functions of the radio 430. Further, each integrated circuit can include circuitry (e.g., first circuitry, second circuitry, etc.) configured to perform the functions of the radio 430.
[0067] Figure 5 An exemplary simplified block diagram of cellular communication circuitry is illustrated in accordance with some embodiments. Note that Figure 5 The block diagram of cellular communication circuitry 330 is merely one example of possible cellular communication circuitry. In accordance with embodiments, the cellular communication circuitry 330 can be included in a communication device such as the communication device 106 described above. As noted above, the communication device 106 can be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop or computing device, a mobile computing device (e.g., laptop, notebook, or portable computing device), a tablet, and / or combinations of devices, among other devices.
[0068] The cellular communication circuitry 330 can be coupled (e.g., communicatively; directly or indirectly) to one or more antennas, such as antennas 335a-b and 336 as shown. In some embodiments, the cellular communication circuitry 330 can include dedicated receive chains for multiple RATs (including and / or coupled to (e.g., communicatively; directly or indirectly) dedicated processors and / or radio components) (e.g., a first receive chain for LTE and a second receive chain for 5G NR). For example, as shown, the cellular communication circuitry 330 can include modem 510 and modem 520. Modem 510 can be configured for communication in accordance with a first RAT (e.g., such as LTE or LTE-A), and modem 520 can be configured for communication in accordance with a second RAT (e.g., such as 5G NR). Figure 5
[0069] As shown, modem 510 can include one or more processors 512 and memory 516 in communication with processors 512. Modem 510 can be in communication with radio frequency (RF) front end 530. RF front end 530 can include circuitry for transmitting and receiving radio signals. For example, RF front end 530 can include receive circuitry (RX) 532 and transmit circuitry (TX) 534. In some embodiments, receive circuitry 532 can be in communication with downlink (DL) front end 550, which can include circuitry for receiving radio signals via antenna 335a.
[0070] Similarly, modem 520 can include one or more processors 522 and memory 526 in communication with processors 522. Modem 520 can be in communication with RF front end 540. RF front end 540 can include circuitry for transmitting and receiving radio signals. For example, RF front end 540 can include receive circuitry 542 and transmit circuitry 544. In some embodiments, receive circuitry 542 can be in communication with DL front end 560, which can include circuitry for receiving radio signals via antenna 335b.
[0071] In some implementations, switch 570 can couple transmit circuitry 534 to an uplink (UL) front end 572. In addition, switch 570 can couple transmit circuitry 544 to UL front end 572. UL front end 572 can include circuitry for transmitting radio signals via antenna 336. Thus, when cellular communication circuitry 330 receives an instruction to transmit according to a first RAT (e.g., supported via modem 510), switch 570 can be switched to a first state that allows modem 510 to transmit signals according to the first RAT (e.g., via a transmit chain including transmit circuitry 534 and UL front end 572). Similarly, when cellular communication circuitry 330 receives an instruction to transmit according to a second RAT (e.g., supported via modem 520), switch 570 can be switched to a second state that allows modem 520 to transmit signals according to the second RAT (e.g., via a transmit chain including transmit circuitry 544 and UL front end 572).
[0072] As described herein, modem 510 can include hardware components and software components for implementing the features described above or for supporting predictive scheduling and various other techniques described herein. For example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium), processor 512 can be configured to implement part or all of the features described herein. Alternatively (or in addition), processor 512 can 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), processor 512, in conjunction with one or more of other components 530, 532, 534, 550, 570, 572, 335, and 336, can be configured to implement part or all of the features described herein.
[0073] In addition, as described herein, processor 512 can include one or more processing elements. Thus, processor 512 can include one or more integrated circuits (ICs) that are configured to perform the functions of processor 512. In addition, each integrated circuit can include circuitry (e.g., a first circuit, a second circuit, etc.) that is configured to perform the functions of processor 512.
[0074] As described herein, modem 520 can include hardware components and software components for implementing the above-described features for supporting predictive scheduling, as well as various other techniques described herein. For example, processor 522 can be configured to implement part or all of the features described herein by executing program instructions stored in a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively (or in addition), processor 522 can be configured as a programmable hardware element(s) such as an FPGA (Field Programmable Gate Array), or as an ASIC (Application Specific Integrated Circuit). Alternatively (or in addition) to the above, processor 522 can be configured, in conjunction with one or more of other components 540, 542, 544, 550, 570, 572, 335, and 336, to implement part or all of the features described herein.
[0075] Further, as described herein, processor 522 can include one or more processing elements. Thus, processor 522 can include one or more integrated circuits (ICs) that are configured to perform the functions of the processor 522. In addition, each integrated circuit can include circuitry (e.g., a first circuit, a second circuit, etc.) configured to perform the functions of the processor 522.
[0076] Figure 6 A network message 602 is illustrated that includes a plurality of information elements (IEs) 604a, 604b, 604c, 604d (collectively, IEs 604). In various embodiments, a variety of network messages 602 composed of one or more information elements can be used for communication between different components. In various such embodiments, one or more network messages 602 in one or more formats can be exchanged between one or more UEs and one or more network components to perform one or more processes or techniques disclosed herein. For example, predictive scheduling of resources can involve the exchange of several network messages 602 between a UE and / or a BS. It should be understood that network messages 602 and IEs 604 can occur in a variety of formats and carry a variety of information. In general, various standards and technical specifications define various network messages 602, IEs 604, and procedures, such as 3GPP technical specifications (e.g., TS 38.300 and TS 38.321). Embodiments are not limited to this context.
[0077] Various techniques to support predictive scheduling for low latency communications are described in greater detail below, such as utilizing predicted resource needs to reduce scheduling latency. Many embodiments disclosed herewith provide resource efficient techniques that adapt to dynamically changing traffic using predictive scheduling. Various embodiments can predict resource needs and request resources based on the predicted resource needs. For example, embodiments can utilize scheduling requests (SRs) and / or buffer status reports (BSRs) to proactively request resources from a base station based on predicted traffic, such as predicted traffic at an anticipated uplink resource grant. In some embodiments, conditional multiple grants can be utilized. For example, multiple grants can be configured simultaneously, and only if a UE cannot fully utilize a previous grant, the UE can use a later grant. In several embodiments, artificial intelligence and / or machine learning can be utilized to predict data packet sizes and packet arrival times. In several such embodiments, these predictions can be used to request resources for data packets before the data packets arrive at a buffer.
[0078] In these and other ways, the components / techniques described herewith can provide a number of technical advantages. For example, the computer-based techniques of the present disclosure improve the functioning of telecommunications systems as compared to conventional approaches because these techniques enable predictive scheduling that can improve accessibility, reduce latency, reduce overhead, and provide extended capabilities for telecommunications systems as compared to conventional approaches. Moreover, the embodiments disclosed herewith can be practically used to improve the functioning of computers and / or improve various technical fields, including telecommunications, computer networking, scheduling, resource utilization, low latency communications, URLLC, artificial intelligence, machine learning, and / or user experience.
[0079] Figure 7 An example block diagram of a UE 702 in conjunction with a BS 704 is illustrated in accordance with some embodiments. In various embodiments, the UE 702 and BS 704 can operate to support predictive scheduling, such as by using scheduling requests and buffer status reports to proactively request resources from the BS 704 based on predicted traffic at an anticipated uplink resource grant and / or by conditional multiple grants in which multiple grants are configured simultaneously with a later grant that a UE uses if it cannot fully utilize a previous grant. In the illustrated embodiment, the UE 702 includes one or more packet generation processes 706, a buffer 708 with packets 710a, 710b, 710c (collectively, packets 710), a buffer monitor 712, a predictor 714 with a ML model 716, an error monitor 718, and a wireless communication manager 720; and the BS 704 includes a resource manager 722 and a model trainer 724. It should be appreciated that Figure 7One or more components of the one or more components can be the same as or similar to one or more other components disclosed herein. For example, the BS 804 can be the same as or similar to the BS 102. In another example, the UE 702 can be the same as or similar to the UE 106. In further examples, the wireless communication manager 720 can include one or more portions of the SOC 300 and / or the cellular communication circuitry 330. Moreover, aspects discussed with respect to various components in the Figure 7 Aspects discussed with respect to various components in the
[0080] In many embodiments, predictive scheduling can generally operate as follows, where the following such as with respect to Figure 8 to Figure 15 Various aspects and / or alternatives of the operation are described in greater detail. The UE 702 can include one or more packet generation processes 706 (such as applications) that generate data for transmission to the BS 704. This data for transmission can be stored in a buffer 708 as data packets 710 until granted resources are available for use by the wireless communication manager 720 to transmit the data packets 710 to the BS 704. In some embodiments, the buffer 708 can include a MAC buffer. With predictive scheduling, the wireless communication manager 720 can proactively request transmission resources, such as based on an output of a predictor 714, before data packets actually arrive at the buffer 708 for transmission. For example, the predictor 714 can include an ML model 716 to determine an anticipated resource requirement for uplink wireless communications (i.e., resources for transmitting payload data from the UE 702 to the BS 704). In some embodiments, the anticipated resource requirement can be determined in response to an arrival of a data packet (e.g., packet 710a) in the buffer 708. In various embodiments, the anticipated resource requirement can include or be based on one or more of a predicted size of the buffer 708 (i.e., a size of content in the buffer 708), a predicted size of anticipated data packets (i.e., data packets that have not yet arrived at the buffer 708), a predicted arrival time of the anticipated data packets in the buffer 708.
[0081] The predictor 714 can utilize the ML model 716 to determine a projected resource demand. The ML model 716 can be trained according to historical resource demands for uplink wireless communications by one or more UEs. In some embodiments, the historical resource demands can include one or more of actual buffer sizes, actual sizes of transmitted data packets, and actual arrival times of transmitted data packets in the buffer 708. In some embodiments, the historical resource demands can be monitored and retained by the buffer monitor 712. As will be discussed in greater detail below, the BS 704 can utilize the model trainer 724 to train and / or retrain the ML model 716. However, without departing from the scope of the present disclosure, the UE 702 or another computing resource (e.g., a cloud server) can be utilized to train and / or retrain the ML model 716.
[0082] In several embodiments, the ML model 716 can utilize one or more of a current packet size and a current packet arrival time as inputs to generate a projected resource demand as an output. For example, the buffer monitor 712 can detect an arrival of a current packet (e.g., packet 710a) in the buffer 708, determine a size of the current packet, and determine a time between an arrival of the current data packet in the buffer 708 and an arrival of a previous data packet (e.g., packet 710b) in the buffer 708. In response, the buffer monitor 712 can provide the size of the current data packet and the time between the arrival of the current data packet and the arrival of the previous data packet as inputs to the ML model 716 to determine a projected resource demand for the uplink wireless communications. In such examples, the projected resource demand for the uplink wireless communications can include a predicted size and an arrival time of a next data packet to arrive in the buffer 708. In some embodiments, the ML model 716 can include a recurrent neural network (RNN), such as a long short-term memory network (LTSM), any feedforward neural network, a random forest. In some embodiments, the model can be an autoregressive model, such as ARIMA, SARIMA, etc. In various embodiments, the data packet size prediction can utilize a LTSM network with 40 hidden nodes, and the packet arrival time prediction can utilize a LTSM network with 60 hidden nodes. In some embodiments, the ML model 716 can include one or more ML models.
[0083] The wireless communication manager 720 can transmit, to the BS 704, a resource request message including an indication of a projected resource need for uplink wireless communications (i.e., a prediction indication). In some implementations, the resource request message can be transmitted during a scheduling request opportunity or in response to a triggering event. For example, as discussed in more detail below, the triggering event can include or be based on one or more of a determination that a difference between a predicted buffer size and an actual buffer size exceeds a threshold, a determination that a predicted buffer size exceeds a threshold, a determination that a confidence level of the projected resource need for uplink wireless communications exceeds a threshold, a determination that a current resource grant fails to satisfy a latency requirement of predicted future latency-sensitive traffic, and a determination of excess resources or excess padding bits in a current grant.
[0084] The resource request message can include one or more of a buffer status report message, a scheduling request message, a medium access control (MAC) control element (CE) message. In various implementations, the resource request message can include or indicate a time at which the projected resource need is needed. For example, the resource request message can indicate an earliest possible grant time and / or a latest possible grant time of the projected resource need. In some implementations, the resource request message can include a prediction indication and / or a legacy indication. The legacy indication can refer to an indication that utilizes scheduling techniques described in existing standards. For example, a legacy BSR can refer to a BSR that indicates an actual size of a buffer rather than a projected size of a buffer. As another example, a legacy BSR can also refer to a BSR that indicates queuing delay information (e.g., a remaining time until a deadline for delivery of buffered data) of a buffer. Based on the resource request message and the prediction indication and / or the legacy indication included therein, the resource manager 722 can assign resources for the UE 702 to transmit data packets via one or more grants. When both the prediction indication and the legacy indication are included in the resource request message, the resource manager 722 can select which indication to utilize in granting resources based on various factors, such as overall network resource utilization, confidence level, and prediction error.
[0085] In various embodiments, the indication of projected resource demand for uplink wireless communications can include a predicted buffer status report value. In various such embodiments, the BS 704 (e.g., resource manager 722) can map the indication of projected resource demand to a buffer size, such as by using a lookup table. The resource manager 722 of the BS 704 can proactively grant resources for uplink wireless communications to the UE 702 with a resource request message that includes the indication of projected resource demand. In some embodiments, the predictor 714 can generate a confidence level regarding the projected resource demand. In some such embodiments, an indication of the confidence level can be included in the resource request message. In various embodiments, the confidence level can be used to determine whether to proactively request resources or proactively grant resources based on the projected resource demand. For example, when the resource request message includes a predicted BSR, a legacy BSR, and a confidence level, the resource manager 722 can utilize the confidence level to determine whether to grant resources based on the predicted BSR or the legacy BSR, such as by comparing the confidence level to a threshold.
[0086] In various embodiments, the error monitor 718 can operate to track an error associated with the projected resource demand. In some embodiments, the error can be used to determine a confidence level associated with the projected resource demand. In various embodiments, when the projected resource demand for uplink wireless communications includes a predicted size of a projected data packet, the error monitor 718 can identify an actual size of the projected data packet when the projected data packet actually arrives at the buffer 708, and determine the error based on a difference between the predicted size and the actual size. In additional or alternative examples, when the projected resource demand for uplink wireless communications includes a predicted arrival time of a projected data packet in the buffer, the error monitor 718 can identify an actual arrival time of the projected data packet when the projected data packet actually arrives at the buffer 708, and determine the error based on a difference between the predicted arrival time and the actual arrival time of the projected data packet in the buffer 708.
[0087] In some embodiments, various fallback and / or reconciliation mechanisms can be used when there is an error condition (e.g., the error exceeds a threshold) or if the UE does not sufficiently utilize the resources granted based on the projected resource demand. For example, the error monitor 718 can monitor the average / maximum error between a predicted BSR and a corresponding actual BSR (legacy BSR), and if the error exceeds a threshold, one or more fallback and / or reconciliation mechanisms can be implemented. The threshold for the error condition can be based on one or more of the BS 704, the UE 702 (e.g., based on a particular implementation), and determined by a specification.
[0088] The various fallback mechanisms and / or mediation mechanisms implemented in response to the error condition can include one or more of the following examples. In a first example, the UE can perform retraining to determine a new ML model when the error exceeds a threshold. In some examples, the UE 702 can retrain the ML model (i.e., generate a new ML model) with a predetermined number of previous data samples (e.g., packet sizes, arrival times, etc.) prior to the input that caused the error condition. In other such examples, the UE 702 can retrain the ML model with a subset of the data samples that caused the largest prediction errors. In a second example, the UE 702 can transmit the data samples (e.g., packet sizes, arrival times, etc.) to the BS 704 to perform retraining (e.g., with the model trainer 724) and transmit the new ML model back to the UE 702. In such examples, the UE 702 can utilize a predetermined number of previous data samples (e.g., packet sizes, arrival times, etc.) prior to the input that caused the error condition. In various implementations, the BS 704 can generate a new ML model using the same application with data samples from one or more other UEs. In a third example, the UE 702 can transmit a subset of the data samples that caused the largest prediction errors to the BS 704 for retraining. In some such examples, the UE can transmit only samples from a predetermined number of previous data samples prior to the input that caused the error condition that reduced the prediction performance by more than a particular level. In a fourth example, the UE 702 can fallback to a non-predictive mode using a legacy BSR, which can result in an increase in scheduling latency. The following describes various modes for the UE 702 in more detail. Figure 8 The various modes for the UE 702 are described in more detail.
[0089] Various fallback mechanisms and / or mediation mechanisms implemented in response to the UE 702 not fully utilizing or failing to utilize the resources granted based on the predicted resource needs can include one or more of the following examples. In a first example, the BS 704 can instruct the UE to retrain the ML model 716. In such examples, the BS 704 can utilize one or more of a radio resource control (RRC) message, a MAC CE message, or a DCI message to inform the UE 702. In a second example, the BS 704 can instruct the UE 702 to switch to a different mode, including a non-predictive mode. In such examples, the BS 704 can utilize one or more of a radio resource control (RRC) message, a MAC CE message, or a DCI message to inform the UE 702. In a third example, the BS 704 can allocate additional transmission resources at a later time to accommodate possible late-arriving traffic at the UE. In many embodiments, the third example mechanism can be utilized when the UE fails to fully utilize the originally granted resources (i.e., first granted, such as in a conditional multi-grant) for transmitting the predicted data packet. In some embodiments, the failure to fully utilize the originally granted resources can be due to one or more of a traffic prediction error at the UE 702 and a temporal jitter of incoming traffic (e.g., packet data units (PDUs)). When the UE fails to fully utilize the first granted resources to transmit the predicted data packet, the UE can utilize the first granted resources to transmit PDUs from other (e.g., non-time sensitive) buffers, the UE can refrain from transmitting any PDUs, and / or the UE can transmit dummy or null data to prevent soft-combining at the BS 704.
[0090] In many embodiments, the format and content of the resource request message and / or other operational aspects can be determined based on the selected mode for predictive scheduling, as described in greater detail below. In many such embodiments, the mode for predictive scheduling can be selected based on various factors, including a confidence level, an error, a network utilization, a traffic level, a latency requirement, a UE capability, a BS capability, and the like.
[0091] Figure 8 A process diagram 800 for predictive scheduling is illustrated, in accordance with some embodiments. The process diagram 800 includes a UE 802 and a BS 804. In various embodiments, the process diagram 800 can illustrate various operations performed and / or messages transmitted and / or received to implement predictive scheduling using a predictive buffer status report. It should be appreciated that Figure 8 One or more components of the UE 802 can be the same as or similar to one or more other components disclosed herein. For example, the UE 802 can be the same as or similar to the UE 702. In another example, the BS 804 can be the same as or similar to the BS 704. Moreover, the UE 802 and / or the BS 804 can include one or more components of the UE 702 and / or the BS 704, respectively, without departing from the scope of the present disclosure. The process diagram 800 can be representative of a process for predictive scheduling, in accordance with some embodiments. Figure 8Aspects discussed in connection with various components in the above-described embodiments can be implemented by one or more other components from one or more other embodiments. The embodiments are not limited in this context.
[0092] In many embodiments, the predictive scheduling can utilize a new BSR format / framework, which is referred to as a predictive BSR. The predictive BSR can be transmitted as a new BSR format or a new type of MAC CE. The transmission of the predictive BSR can be periodic or trigger-based. In various embodiments, the triggering conditions can include one or more of the following examples. In a first example, the predictive BSR can be transmitted in spare resources or padding bits if there is extra space in the grant. In one embodiment, this first example can utilize similar features / mechanisms as associated with the legacy padding BSR described in TS 38.321. In a second example, the UE 802 can transmit a predictive BSR or an SR in an SR opportunity if there is no grant that satisfies the latency requirement of the predicted future latency-sensitive traffic. In a third example, the predictive BSR can be transmitted when the predicted buffer size exceeds a threshold. In a fourth example, the predictive BSR can be transmitted when the difference between the predicted buffer size and the current (actual) buffer size exceeds a threshold. In a fifth example, the predictive BSR can be transmitted when the prediction confidence level exceeds a threshold. In various embodiments, the UE capability can include support for the predictive BSR feature and UE preference for specific modes described below.
[0093] The process diagram 800 can begin with the UE 802 and the BS 804 engaging in predicting BSR mode configuration and activation 812. During this process, multiple UE BSR feedback modes can be configured, and the UE 802 and / or the BS 804 can activate one of these UE BSR feedback modes for the UE 802 at a time. Based on the mode, the UE can transmit at least one of the following in a message 806 along with data packets. In a first mode, a legacy BSR including an exact / quantized BSR can be transmitted. The first mode can be referred to as a non-predictive mode or a legacy mode. The remaining modes that determine a projected resource requirement can be referred to as predictive modes. In a second mode, a predictive BSR has an indication of a predicted BSR value (for mapping to a table) at an expected grant time (e.g., multiple transmission time intervals (TTIs)). In various embodiments, the second mode can assume a fixed scheduling delay. In a third mode, a predictive BSR and a time of a requested resource can be transmitted. In some embodiments of the third mode, the predictive BSR and the time of the resource can be transmitted as a tuple. In some such embodiments, multiple tuples can be transmitted to provide some scheduling flexibility to the BS 804. In various embodiments of the third mode, each BSR value can be accompanied by two time values: an earliest possible grant time and a latest acceptable grant time (to meet latency requirements). In a fourth mode, a combination of a legacy BSR and a predictive BSR can be transmitted. In the fourth mode, the BS 804 can adjust the grant for the predictive portion based on factors such as overall network resource utilization, prediction accuracy, etc. In various embodiments, additional information (e.g., a confidence level) can be added to the predictive BSR in one or more of the above modes. In various such embodiments, a range (e.g., an upper and / or lower bound on prediction error) can be specified for the confidence level.
[0094] In various such embodiments, when multiple BSRs are triggered and there is an upper limit on the number of allowed BSRs in a transport block (i.e., MAC PDU) (e.g., a maximum of 1, as in 5G NR), the UE can determine which mode (or BSR format) to utilize. For example, the UE can always prioritize a legacy BSR, always prioritize a predictive BSR, make a determination based on a priority level of the LCH / LCG associated with each triggered BSR, and / or make a determination based on a configuration of the BS 804.
[0095] In various embodiments, padding bits can be available in uplink communications. In various such embodiments, the UE can determine which mode (or BSR format) to utilize when padding bits are available. For example, the UE can always prioritize legacy BSRs, always prioritize predictive BSRs, make a determination based on a priority level of the LCH / LCG associated with each BSR, make a determination based on a configuration of the BS 804, and / or make a determination based on a number of available padding bits. In some embodiments, predictive scheduling can be activated and / or deactivated based on various parameters, such as a prediction accuracy. Thus, in various embodiments, predicted resource needs can be generated and a level of error tracked, regardless of whether they are used to proactively request resources. For example, predicted resource needs can only be used to proactively request resources when a current prediction accuracy level is above a threshold accuracy level.
[0096] In many embodiments, activation of the prediction, specific predictive feedback mode, fallback, and / or deactivation procedures can include one or more of the following. In some embodiments, predictive BSR feedback at the UE can be configured for specific traffic flows and / or logical channel groups (LCGs). For example, the UE 802 and BS 804 can first negotiate which LCG or logical channel (LCH) can utilize the predictive scheduling mode, and then the BS 804 can be configured accordingly. In some embodiments, the UE 802 can activate a previously configured predictive BSR feedback mode by transmitting a MAC-CE or BSR for the configured LCG or LCH.
[0097] In various embodiments, predictive BSR feedback at the UE can be configured with a reporting criteria (e.g., the network can configure the UE to only provide a predictive BSR if a confidence level is above a certain threshold). In various such embodiments, the network can change the threshold based on various parameters, such as load, traffic class, assigned quality of service (QoS), etc. For example, the functionality of predictive BSRs can be enabled at the UE when a confidence level at the UE exceeds a threshold. In such instances, the UE starts predicting, but only reports the predictions (i.e., communicates these predictions to the BS) when the threshold confidence level is exceeded.
[0098] In many embodiments, different modes can be activated / deactivated by the UE 802 or BS 804 under different conditions. For example, the UE 802 can deactivate the predictive mode when the error exceeds a threshold or when no uplink low latency traffic is available. The UE 802 can deactivate the predictive mode with one or more of a MAC-CE or BSR with zero values. In another example, the BS 804 can deactivate the predictive mode by transmitting a MAC-CE, DCI, or RRC message when the prediction error exceeds a threshold.
[0099] In several embodiments, the addition of predictive scheduling and predictive mode can utilize modified or additional BSR tables (e.g., corresponding to BSR values). For example, a legacy BSR table can be modified to reassign some of the values to predictive BSR feedback (e.g., projected resource needs). In another example, an additional BSR table for predictive BSR feedback can be utilized. In one embodiment, different tables can be used for each mode. In either of the foregoing examples, the modified or additional predictive BSR mode table can be preconfigured by the network and conveyed to the UE such as via a system information block (SIB) and / or RRC message, or the modified or additional predictive BSR mode table can be negotiated between the UE and the BS. The negotiation can utilize some signaling exchange to reach a common understanding regarding the structure, format, and / or content of the table. For example, the UE / BS can indicate a maximum and / or minimum value of the predictive buffer size and a step size in the table.
[0100] Referring back to the process diagram 800, in the illustrated embodiment, the message 806 includes data and a predictive BSR. In response to the message 806, the BS 804 can grant resources to the UE 802 based on the projected resource needs in the message 808, which includes a downlink control information (DCI) grant. Next, the UE 802 can send data and another predictive BSR to the BS 804 in the message 810. In many embodiments, the data in the message 810 can correspond to the projected data packet or projected data packets indicated by the predictive BSR in the message 806.
[0101] Figure 9 Various aspects of predictive scheduling are illustrated in accordance with some embodiments. The illustrated embodiments include a schematic diagram 900 that illustrates the exchange of messages 912a, 912b, 912c, 912d, 912e, 912f (collectively, messages 912) corresponding to predictive scheduling between a BS 902 and a UE 904 in conjunction with the contents of a UE data buffer 906. The schematic diagram 900 includes a time axis 930, where time increases toward the right side of the page. Thus, the schematic diagram 900 illustrates the exchange of the messages 912 and the contents of the UE data buffer 906 over time in an example embodiment of predictive scheduling. Additionally, the boxes correspond to transmission time slots for transmitting and receiving signals between the BS 902 and the UE 904, where the shaded boxes correspond to periodic scheduling request opportunities 908. The schematic diagram 900 also includes predictive times 910a, 910b, 910c, 910d (collectively, predictive times 910). It should be understood that, Figure 9One or more components of the example of FIG. 9 can be the same as or similar to one or more other components disclosed herein. For example, UE data buffer 906 can be the same as or similar to buffer 708. In another example, message 912c can be the same as or similar to message 806, and message 912d can be the same as or similar to message 808. Moreover, aspects discussed with respect to various components in Figure 9 Aspects discussed with respect to various components in
[0102] In the diagram 900, initially data packet 914 can arrive at UE data buffer 906. Next, data packet 916 can arrive at UE data buffer 906. Then, at predicted time 910a, UE 904 can transmit message 912a including a scheduling request with an indication of projected resource needs, including resources for the predicted arrival of data packet 918. After sending message 912a, data packet 918 can actually arrive at UE data buffer 906. In response to message 912a, BS 902 can transmit message 912b including DCI with a resource grant based on the projected resource needs. Then, BS 904 can utilize resources granted based on the new projected resource needs to transmit data packets 914, 916, 918 (corresponding to transmitted packets 922) and the new projected resource needs included in the predicted BSR in message 912c to BS 902 at predicted time 910b. Thus, by communicating projected resource needs, the scheduling latency of data packet 918 is reduced. Additionally, the contents of UE data buffer 906 are reduced by an amount proportional to the size of transmitted packets 922 (i.e., data packets 914, 916, 918), and only data packet 920 remains in UE data buffer 906.
[0103] After message 912c is sent, data packet 924 can reach UE data buffer 906. Next, in response to message 912c, BS 902 can transmit message 912d, which includes DCI with resource allocation, based on the new projected resource requirements. UE 904 can then use the resources allocated based on the new projected resource requirements to send data packets 920 and 924 (corresponding to the sent packet 926) to BS 902 in message 912e. Therefore, by communicating the projected resource requirements, the scheduling delay of data packet 924 is reduced. Additionally, the content of UE data buffer 906 is reduced by an amount proportional to the size of the sent packet 926 (i.e., data packets 920 and 924), and no data packets remain in UE data buffer 906. Furthermore, because sufficient resources are allocated based on the new projected resource requirements to send all packets in UE data buffer 906, message 912e does not include another new projected resource requirement at prediction time 910c. Conversely, for example, message 912e may include a zero BSR value configured to disable the predicted BSR mode and fall back to the non-predictive BSR mode. Subsequently, data packet 928 may arrive at UE data buffer 906, and at prediction time 910d, UE 904 may transmit message 912f including a scheduling request with an indication of anticipated resource requirements, which include resources for the predicted arrival of future data packets.
[0104] Figure 10 An operational configuration 1000 for predictive scheduling is illustrated according to some embodiments. In various embodiments, a lower layer (e.g., one or more layers or sublayers below the application layer of an Open Systems Interconnection (OSI) model) may be utilized to perform prediction and monitor prediction errors. Therefore, the illustrated embodiment includes an application 1002 and a lower layer 1004 having a predictor 1006 and an error monitor 1008. In many embodiments, application 1002 may provide the lower layer with data 1010 (e.g., expected business parameters) for sending and / or performing predictions. It should be understood that... Figure 10 One or more components may be identical or similar to one or more other components disclosed herein. For example, application 1002 may be identical or similar to grouping generation process 706. In another example, predictor 1006 may be identical or similar to predictor 714, and / or error monitor 1008 may be identical or similar to error monitor 718. Furthermore, without departing from the scope of this disclosure, regarding Figure 10 The various components discussed herein can be implemented by one or more other components from one or more other implementations. Implementations are not limited to this context.
[0105] Figure 11A and Figure 11BOperational structures 1100a and 1100b for predictive scheduling are illustrated according to some implementation schemes. In various implementations, executable predictions are applied, while lower layers are used to monitor prediction errors. Therefore, Figure 11A This includes an application 1102 with a predictor 1106 and a lower layer 1104 with an error monitor 1108, and Figure 11B This includes application 1114a with predictor 1118a, application 1114b with predictor 1118b, and a lower layer 1116 with aggregator 1120 and error monitor 1126. In many embodiments, the application performing the prediction may provide the lower layer with data including data for transmission and grouped prediction reports. Additionally, the lower layer may provide the application with data for configuration and error status reporting. It should be understood that... Figure 11A and / or Figure 11B One or more components may be identical or similar to one or more other components disclosed herein. For example, applications 1114a, 1114b may be identical or similar to grouping generation process 706. In another example, predictors 1118a, 1118b may be identical or similar to predictor 714, and / or error monitor 1126 may be identical or similar to error monitor 718. Furthermore, without departing from the scope of this disclosure, regarding Figure 11A and / or Figure 11B The various components discussed herein can be implemented by one or more other components from one or more other implementations. Implementations are not limited to this context.
[0106] exist Figure 11A and Figure 11B In this context, the application layer can assist the lower layer in predicting future packet arrivals. Thus, application 1102 can send data and prediction reports 1110 to the lower layer 1104 and receive configuration and error status 1112 from the lower layer 1104. Similarly, application 1114a can send data and prediction reports 1122a to the lower layer 1116 and receive configuration and error status 1124a from the lower layer 1116, and application 1114b can send data and prediction reports 1122b to the lower layer 1116 and receive configuration and error status 1124b from the lower layer 1116. More generally, collaboration between applications and the lower layer can include context-aware predictive scheduling (e.g., predictive scheduling utilizing context data). In some implementations, context data can include information indicating future resource needs, such as anticipated business parameters. For example, context data can include data indicating how an application is used or will be used, providing relevant information about future resource needs (e.g., standalone mode, online mode, streaming mode, etc.).
[0107] In various embodiments, the applications 1102, 1114a, 1114b can include instances of URLLC applications that provide expected traffic parameters to the lower layers 1104, 1116. In various such embodiments, the lower layers 1104, 1116 (e.g., MAC) can perform one or more of the following example operations. In a first example, the lower layers can aggregate reports from multiple applications (e.g., if multiple applications are running on the same QoS flow). Thus, the aggregator 1120 can aggregate reports from the applications 1114a, 1114b operating on the same QoS flow. In a second example, the lower layers can map the upper layer prediction reports to a predicted BSR. In a third example, the lower layers can monitor traffic and check the accuracy of the upper layer prediction reports. In a fourth example, the lower layers can provide the prediction configuration (e.g., pattern) and / or monitoring status to the upper layers.
[0108] Figure 12 A flow diagram 1200 for predictive scheduling is illustrated in accordance with some embodiments. Aspects of the flow diagram 1200 can be related to the various embodiments described herein. In many embodiments, the processes of the flow diagram 1200 can be performed by one or more UEs. It should be understood that aspects of the flow diagram 1200 discussed with respect to various components can be implemented by one or more other components from one or more other embodiments without departing from the scope of the present disclosure. The embodiments are not limited in this context.
[0109] The flow diagram 1200 begins at block 1202. At block 1202, a predicted BSR mode can be configured and activated. For example, the UE 702 and the BS 704 can operate to configure and activate a predicted BSR mode. Proceeding to decision block 1204, it can be determined whether the buffer is empty. For example, the buffer monitor 712 of the UE 702 can determine whether the buffer 708 is empty. If the buffer is empty, the flow diagram 1200 can return to decision block 1204. For example, the buffer monitor 712 can periodically check the buffer until the buffer is no longer empty, such as due to the arrival of a packet 710a to the buffer 708. In some embodiments, the buffer can include a MAC buffer.
[0110] When the buffer is not empty, flowchart 1200 can continue to block 1206. At block 1206, a scheduling request can be transmitted in a scheduling request opportunity. For example, UE 702 can transmit a scheduling request to BS 704. In many such examples, the scheduling request can include an anticipated resource need for uplink wireless communications needed by UE 702. In some embodiments, the anticipated resource need for uplink wireless communications can be determined by predictor 714. For example, in response to an arrival of a packet in buffer 708, predictor 714 can utilize ML model 716 to determine the anticipated resource need. In several embodiments, the anticipated resource need can include a predicted size of a future packet and a predicted arrival time of the future packet in buffer 708. In several such embodiments, ML model 716 can utilize a size of a current packet (e.g., a packet that turns buffer 708 from empty to non-empty) and an arrival time of the current packet as inputs to determine the anticipated resource need. In many embodiments, the arrival time of the current packet can include an inter-arrival time relative to a previous packet. In other words, the arrival time of the current packet can be an amount of time between an arrival of an immediately preceding packet and an arrival of the current packet.
[0111] In response to transmitting the scheduling request, a DCI can be received at block 1208. For example, UE 702 can receive a DCI including a resource grant from BS 704 in response to transmitting the scheduling request. The resource grant in the DCI can include resources such as determined by resource manager 722 based on the anticipated resource need indicated in the scheduling request. In many embodiments, the resource grant in the DCI can include a plurality of grants and a plurality of times corresponding to the plurality of grants (e.g., conditional multiple grants).
[0112] At decision block 1210, it can be determined whether data arrived at the buffer before the first grant time. For example, the buffer monitor 712 and / or the wireless communication manager 720 of the UE 702 can determine whether a predicted packet corresponding to a predicted resource need arrived at the buffer 708 before the first grant time. If data has arrived at the buffer before the first grant time, at block 1212, the data can be transmitted to the BS along with a new predicted BSR to the BS. In some embodiments, the new predicted BSR can be generated based on the predicted packet in response to the arrival of the predicted packet in the buffer 708. However, if data has not arrived at the buffer before the first grant time, the UE can transmit data from another buffer, if available, in the granted resources at block 1214. In various embodiments, the UE can transmit the data packet that made the buffer not empty at decision block 1204 in the granted resources. In one embodiment, data from another buffer and the data packet that made the buffer not empty at decision block 1204 can be transmitted in the granted resources. If no data is available for transmission at block 1214, dummy data or null data can be transmitted. The dummy data or null data can include a predetermined bit sequence configured to prevent soft combining at the BS.
[0113] Proceeding to decision block 1216, it can be determined whether data arrived before an additional grant time after the first grant time. For example, the buffer monitor 712 and / or the wireless communication manager 720 of the UE 702 can determine whether a predicted packet corresponding to a predicted resource need arrived at the buffer 708 before the additional grant time. If data has arrived at the buffer before the additional grant time, at block 1218, the data can be transmitted to the BS along with a new predicted BSR to the BS. In some embodiments, the new predicted BSR can be generated based on the predicted packet in response to the arrival of the predicted packet in the buffer 708. However, if data has not arrived at the buffer before the additional grant time, the UE can transmit data from another buffer, if available, in the granted resources at block 1214. In some embodiments, the UE can transmit the data packet that made the buffer not empty at decision block 1204 in the granted resources. In one embodiment, data from another buffer and the data packet that made the buffer not empty at decision block 1204 can be transmitted in the granted resources. If no data is available for transmission at block 1220, dummy data or null data can be transmitted. The dummy data or null data can include a predetermined bit sequence configured to prevent soft combining at the BS.
[0114] Continuing to decision block 1222, a determination can be made as to whether conditions for UE fallback are met. For example, error monitor 718 can determine whether the prediction accuracy is below a threshold, such as by comparing the actual arrival time and predicted arrival time of one or more previous data packets and / or the actual data packet size and predicted data packet size. UE fallback can refer to switching to a different mode, such as from a predicted BSR mode to a non-predicted BSR mode. If the conditions for UE fallback are met (e.g., the error exceeds the threshold), the UE can send outlier input values to the BS at block 1224 for retraining. For example, the outlier input values can include the values provided to ML model 716 that ultimately resulted in the error. For example, the predicted arrival time and predicted size of the data packet that has not yet arrived at the buffer at decision block 1216. In some embodiments, based on the outlier input values, BS 704 can generate a new machine learning model and communicate the machine learning model to UE 702 to replace ML model 716. In one embodiment, the retraining can be performed by UE 702 or a cloud server. If the conditions for UE fallback are not met, flowchart 1200 can return to decision block 1204 and determine whether the buffer is empty.
[0115] Figure 13 A process diagram 1300 for predicted scheduling is illustrated in accordance with some embodiments. Process diagram 1300 includes UE 1302 and BS 1304. In various embodiments, process diagram 1300 can illustrate various aspects of operations performed and messages communicated and / or received to implement predicted scheduling using predicted buffer status reporting. It should be appreciated that Figure 13 One or more components of process diagram 1300 can be the same as or similar to one or more other components disclosed herein. For example, UE 1302 can be the same as or similar to UE 702 and / or UE 106. In another example, BS 1304 can be the same as or similar to BS 704 and / or BS 102. Moreover, aspects discussed with respect to various components in process diagram 1300 can be implemented by one or more other components from one or more other embodiments. Embodiments are not limited in this context. Figure 13 Aspects discussed with respect to various components in process diagram 1300 can be implemented by one or more other components from one or more other embodiments. Embodiments are not limited in this context.
[0116] The process diagram 1300 can begin at process 1306, where a predictive BSR mode is configured. For example, the configuration of the predictive BSR mode includes one or more of setting a mode of predictive scheduling (e.g., content / format of a resource request message), determining whether to allow other traffic (such as traffic from other buffers when predicted latency sensitive traffic is not available to send), determining a predictive BSR table configuration, and activating a configuration (e.g., a threshold prediction accuracy before sending a predicted resource demand). At process 1308a, the UE 1302 can begin generating a predicted resource demand and tracking an error level of the predicted resource demand. At process 1308b, the UE 1302 can determine that the prediction error is low enough to begin sending the predicted resource demand to the BS 1304 for predictive scheduling.
[0117] Continuing to process 1310a, the UE 1302 can activate the predictive BSR mode by transmitting a predictive BSR mode activation request to the BS 1304. In various embodiments, the request can include one or more of an indicated BSR fallback mode (e.g., retrain the ML model, transmit data samples to the BS to retrain the ML model, transmit a subset of data samples to the BS to retrain the ML model, switch to a non-predictive BSR mode), a BSR table configuration, and a conditional multiple grant configuration (e.g., CMG activation status, number of additional grants, CMG resource group, UE behavior for unused grants (send from other queues / buffers, send dummy or empty data, leave empty)). At process 1310b, the BS 1304 can transmit a predictive BSR mode activation response indicating successful activation of the predictive mode.
[0118] Proceeding to process 1312a, the UE 1302 can transmit a scheduling request to the BS 1304 including a predicted resource demand (or an indication thereof). For example, the predicted resource demand can include a predicted size of future data packets and a predicted arrival time of the future data packets in the buffer. At process 1312b, the BS 1304 can send a resource grant to the UE 1302 in response to the scheduling request. The resource grant can be based on the predicted resource demand and include multiple resource grants (e.g., conditional multiple grants). In various embodiments, the number of grants can vary dynamically, such as based on the prediction error. Future data packets can arrive at the buffer at process 1314 prior to process 1312c.
[0119] At process 1312c, a data packet can be transmitted to the BS 1304 in a first grant of granted resources along with a predicted BSR. The predicted BSR can indicate a predicted resource demand, such as based on an arrival of a data packet in the buffer at process 1314. The predicted resource demand can again include a predicted size of another future data packet and a predicted arrival time of the other future data packet in the buffer. At process 1316a, the UE 1302 can receive another grant of multiple resources, such as in DCI. The predicted arrival time of the other future data packet in the buffer can be indicated by process 1318a. However, this time future data packet does not actually arrive until process 1318a, which is after the first grant of multiple resources. Thus, at process 1316b, the first grant can be used to transmit data from other buffers and / or queues. At process 1316c, the DCI with the second grant is received at the UE 1302. Thus, in various embodiments, each grant in a conditional multi-grant can be indicated separately, such as with separate DCI (e.g., at processes 1316a and 1316c). However, in other embodiments, only a single DCI can be used to indicate each of the conditional multi-grants (e.g., process 1316a indicates the grant and grant time corresponding to processes 1316b and 1316d).
[0120] Continuing to process 1318b, the future data packet can actually be received in the buffer. Thus, at process 1316d, the future data packet and another predicted BSR can be transmitted to the BS 1304. Additionally, a prediction error can be determined based at least in part on a difference between the predicted arrival time at process 1318a and the actual arrival time at process 1318b. At process 1320a, the UE 1302 can transmit a predicted BSR mode deactivation request to the BS 1304, such as in response to the computed error exceeding a threshold (e.g., a number of prediction errors of one or more previous predictions, such as the previous four predictions). At process 1320b, the BS 1304 can transmit a response to the predicted BSR mode deactivation request to confirm deactivation of the predicted BSR mode. In some embodiments, the BS 1304 can transmit a predicted BSR mode deactivation request to the UE, and the UE 1302 can confirm the deactivation.
[0121] Figure 14A logical flow 1400 illustrating example techniques associated with predictive scheduling, in accordance with some embodiments, is illustrated. In some embodiments, the logical flow 1400 can be performed by a UE. Aspects of the logical flow 1400 can involve various embodiments described herein. The logical flow 1400 can begin at block 1402. Block 1402 can include determining a projected resource demand for uplink wireless communications. The projected resource demand for uplink wireless communications can be determined utilizing a ML model trained according to historical resource demands for uplink wireless communications by one or more UEs. For example, the UE 702 can utilize the ML model 716 of the predictor 714 to determine a projected resource demand for uplink wireless communications. In several embodiments, the model trainer 724 of the BS 704 can be utilized to train the ML model 716 based on historical resource demands for uplink wireless communications by one or more UEs. Once trained, the BS 704 can transmit the ML model 716 to the UE 702.
[0122] At block 1404, a resource request message including an indication of the projected resource demand for uplink wireless communications can be transmitted to a base station. For example, the wireless communication manager 720 of the UE 702 can transmit a resource request message to the BS 704. Continuing to block 1406, a resource grant including granted resources corresponding to the projected resource demand for uplink wireless communications can be identified. For example, the UE 702 can identify DCI that grants resources corresponding to the projected resource demand for uplink wireless communications.
[0123] Figure 15 A logical flow 1500 illustrating example techniques associated with predictive scheduling, in accordance with some embodiments, is illustrated. In some embodiments, the logical flow 1500 can be performed by a BS. Aspects of the logical flow 1500 can involve various embodiments described herein. The logical flow 1500 can begin at block 1502. Block 1502 can include identifying historical resource demands for uplink wireless communications by a UE. For example, the BS 704 can identify historical resource demands for uplink wireless communications by the UE 702.
[0124] Continuing to block 1504, a machine learning model can be trained to determine a projected resource demand for uplink wireless communications by the UE. For example, the model trainer 724 of the BS 704 can train the ML model 716 to determine a projected resource demand for uplink wireless communications by the UE 702. At block 1506, the ML model can be transmitted to the UE. For example, the BS 804 can transmit the ML model 716 to the UE 702 after training.
[0125] Proceeding to block 1508, an indication of a projected resource demand for uplink wireless communication by the UE can be identified in the resource request message. For example, the BS 704 can identify the indication of the projected resource demand for uplink wireless communication by the UE 702 based on the transmission from the UE 702 including the projected resource demand for uplink wireless communication determined by the ML model 716. At block 1510, resources can be granted to the UE based on the projected resource demand for wireless communication by the UE. For example, the BS 704 can transmit DCI with one or more resource grants determined based on the indication of the projected resource demand for uplink wireless communication by the UE.
[0126] Portions of what has been described above can be implemented with logic circuitry, such as an application specific integrated circuit, or with a microcontroller or other form of handling core that executes program code instructions. Thus, the processes taught by the foregoing discussion can be performed using program code such as machine executable instructions that cause a machine to perform certain functions. In this context, a "machine" can be a machine that converts intermediate form or "abstract" instructions into specific processor 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), which is designed to execute instructions such as a general- purpose processor and / or a special- purpose processor. The processes taught by the foregoing discussion can also be performed by (in addition to or in place of a machine) electronic circuitry that is designed to perform the processes (or a portion thereof) without the need to execute software.
[0127] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus can be specially constructed for the required purposes, or it can comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer readable storage medium, such as, but 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.
[0128] The machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, the machine-readable medium includes read-only memory ("ROM"); random access memory ("RAM"); magnetic disk storage media; optical storage media; flash memory devices; etc.
[0129] The article of manufacture can be a product that stores program code for use by or in connection with an instruction execution system. The program code can be embodied in any of a number of ways, including but not limited to a machine-readable storage medium (e.g., any type of disk including floppy disks, hard disks, optical disks, CD-ROMs, and magnetic tapes), a memory (e.g., random access memory (static, dynamic or other)), a media cartridge, a media cassette, or any other medium suitable for storing program code in a manner that causes one or more processing devices to carry out instructions. Program code can also be transmitted or received by one or more electronic devices via a communication link (e.g., a network connection) using a communication medium (e.g., a wireless communication link via the Internet or other communication link via a wired medium).
[0130] A number of example embodiments are described herein.
[0131] Example 1 is a method for wireless communication by a user equipment (UE), the method comprising: determining a projected resource requirement for uplink wireless communication, the projected resource requirement for uplink wireless communication being determined with a machine learning (ML) model trained according to historical resource requirements for uplink wireless communication by one or more UEs; transmitting, to a base station (BS), a resource request message including an indication of the projected resource requirement for uplink wireless communication; and identifying a resource grant including granted resources corresponding to the projected resource requirement for uplink wireless communication.
[0132] Example 2 is the method of Example 1, which can optionally include the projected resource requirement for uplink wireless communication comprising a predicted buffer size.
[0133] Example 3 is the method of Example 1, which can optionally include the projected resource requirement for uplink wireless communication comprising a predicted size of a projected data packet and a predicted arrival time of the projected data packet in a buffer.
[0134] Example 4 is the method of Example 3, which can optionally include identifying an actual size of the projected data packet; and determining an error in the projected resource requirement for uplink wireless communication based on a comparison of the predicted size of the projected data packet and the actual size of the projected data packet in the buffer.
[0135] Example 5 is the method of Example 3, which can optionally include identifying an actual arrival of the projected data packet in the buffer; and determining an error in the projected resource requirement for uplink wireless communication based on a comparison of the predicted arrival time of the projected data packet in the buffer and the actual arrival time of the projected data packet in the buffer.
[0136] Example 6 is the method of Example 1, which can optionally include determining the projected resource requirement for uplink wireless communications in response to an arrival of a current data packet in a buffer.
[0137] Example 7 is the method of Example 1, which can optionally include providing input to the ML model based on one or more of a current packet size and a current packet arrival time in a buffer to determine the projected resource requirement for uplink wireless communications.
[0138] Example 8 is the method of Example 1, which can optionally include detecting an arrival of a current data packet in a buffer, determining a size of the current data packet, determining a time between an arrival of the current data packet in the buffer and an arrival of a previous data packet in the buffer, and providing the size of the current data packet and the time between the arrival of the current data packet and the arrival of the previous data packet as input to the ML model to determine the projected resource requirement for uplink wireless communications.
[0139] Example 9 is the method of Example 1, which can optionally include the ML model comprising a recurrent neural network (RNN).
[0140] Example 10 is the method of Example 9, which can optionally include the RNN comprising a long short-term memory network.
[0141] Example 11 is the method of Example 1, which can optionally include the historical resource requirements for uplink wireless communications comprising actual sizes of transmitted data packets and actual arrival times of the transmitted data packets in a buffer.
[0142] Example 12 is the method of Example 1, which can optionally include the resource request message comprising one or more of a buffer status report (BSR) message, a scheduling request (SR) message, and a medium access control (MAC) control element (CE) message.
[0143] Example 13 is the method of Example 12, which can optionally include the resource request message being transmitted during an SR opportunity.
[0144] Example 14 is the method of Example 1, which can optionally include the indication of the projected resource requirement for uplink wireless communications transmitted to the BS comprising a predicted buffer status report value.
[0145] Example 15 is the method of Example 1, the method can optionally include the resource request message sent to the BS includes a time at which the projected resource demand is needed.
[0146] Example 16 is the method of Example 15, the method can optionally include the time at which the projected resource demand is needed includes an earliest possible grant time and a latest acceptable grant time.
[0147] Example 17 is the method of Example 1, the method can optionally include determining a confidence level of the projected resource demand for uplink wireless communications.
[0148] Example 18 is the method of Example 17, the method can optionally include sending the resource request message in response to the confidence level exceeding a threshold confidence level.
[0149] Example 19 is the method of Example 17, the method can optionally include the resource request message includes the confidence level of the projected resource demand.
[0150] Example 20 is the method of Example 1, the method can optionally include the projected resource demand for uplink wireless communications is determined, and the resource request message is sent to the BS based on a preconfigured periodicity.
[0151] Example 21 is the method of Example 1, the method can optionally include the resource request message is sent to the BS based on a triggering event.
[0152] Example 22 is the method of Example 21, the method can optionally include the triggering event includes determining a difference between a predicted buffer size and an actual buffer size exceeds a threshold.
[0153] Example 23 is the method of Example 21, the method can optionally include the triggering event includes determining a predicted buffer size exceeds a threshold.
[0154] Example 24 is the method of Example 21, the method can optionally include the triggering event includes determining a confidence level of the projected resource demand for uplink wireless communications exceeds a threshold.
[0155] Example 25 is the method of Example 21, the method can optionally include the triggering event includes determining a current grant fails to meet a latency requirement of predicted future latency-sensitive traffic.
[0156] Example 26 is a method as described in Example 21, which can optionally include that the trigger event includes determining excess resources in a current grant or excess padding bits.
[0157] Example 27 is a method as described in Example 1, which can optionally include determining a difference between the projected resource demand for uplink wireless communications and an actual resource demand for uplink wireless communications, and initiating retraining of the ML model when the difference between the projected resource demand and the actual resource demand exceeds a threshold.
[0158] Example 28 is a method as described in Example 1, which can optionally include that the resource grant includes a conditional multi-grant, the conditional multi-grant including a plurality of grants and a plurality of grant times corresponding to the plurality of grants.
[0159] Example 29 is a user equipment (UE) comprising one or more processors configured to perform a method as described in any of Examples 1-28.
[0160] Example 30 is a non-transitory machine-readable medium having executable instructions for causing one or more processing units to perform a method as described in any of Examples 1-28.
[0161] Example 31 is a method for wireless communication resource assignment by a base station (BS), the method comprising: identifying historical resource demands for uplink wireless communications by a user equipment (UE); training a machine learning model to determine a projected resource demand for uplink wireless communications by the UE; sending the ML model to the UE; identifying an indication of a projected resource demand for uplink wireless communications by the UE in a resource request message; and granting resources to the UE based on the projected resource demand for wireless communications by the UE.
[0162] Example 32 is a method as described in Example 31, which can optionally include that the ML model includes a recurrent neural network (RNN).
[0163] Example 33 is a method as described in Example 32, which can optionally include that the RNN includes a long short-term memory network.
[0164] Example 34 is a method as described in Example 31, which can optionally include that the resource request message includes one or more of: a buffer status report (BSR) message, a scheduling request (SR) message, and a medium access control (MAC) control element (CE) message.
[0165] Example 35 is a method as in Example 31, which can optionally include the actual size of transmitted data packets and actual arrival times of the transmitted data packets in a buffer for the historical resource demand for uplink wireless communications.
[0166] Example 36 is a method as in Example 31, which can optionally include the indication of the projected resource demand for uplink wireless communications includes a predicted buffer status report (BSR).
[0167] Example 37 is a method as in Example 36, which can optionally include the predicted BSR is received with a legacy BSR.
[0168] Example 38 is a method as in Example 37, which can optionally include determining an overall network resource utilization; and granting the resource to the UE based on the overall network resource utilization based on the predicted BSR instead of the legacy BSR.
[0169] Example 39 is a method as in Example 37, which can optionally include the predicted BSR is received with a confidence level of the predicted BSR, and the method further includes determining that the confidence level of the predicted BSR exceeds a threshold; and granting the resource to the UE based on the confidence level exceeding the threshold based on the predicted BSR instead of the legacy BSR.
[0170] Example 40 is a method as in Example 31, which can optionally include the indication of the projected resource demand for uplink wireless communications includes a time at which the projected resource demand is needed, and the resource is granted to the UE based on the time at which the projected resource demand is needed.
[0171] Example 41 is a method as in Example 40, which can optionally include the time at which the projected resource demand is needed includes an earliest possible grant time and a latest acceptable grant time.
[0172] Example 42 is a method as in Example 31, which can optionally include identifying an updated historical resource demand for uplink wireless communications of the UE, the updated historical resource demand corresponding to a prediction error; and retraining the ML model based on the updated historical resource demand for uplink wireless communications of the UE.
[0173] Embodiment 43 is in accordance with the method of embodiment 31, which can optionally include the resources granted to the UE including a plurality of grants and a plurality of grant times corresponding to the plurality of grants.
[0174] Embodiment 44 is a base station (BS) comprising one or more processors configured to perform the method of any of claims 31-43.
[0175] Embodiment 45 is a non-transitory machine-readable medium having executable instructions for causing one or more processing units to perform the method of any of claims 31-43.
[0176] Embodiment 46 is a baseband processor configured to perform the method of any of claims 31-43.
[0177] Embodiment 47 is a baseband processor configured to perform the method of any of embodiments 1-28.
[0178] The foregoing detailed description has presented the algorithmic aspects of various embodiments. The novel algorithms described herein can be implemented by software including modular programming languages such as "C"; or interpreted languages such as Perl. The software implementing the present embodiments can be operated in standalone mode or pursuant to requests made by one or more other systems or components.
[0179] It should be borne 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 memories or registers into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[0180] The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems can be used with programs in accordance with the teachings herein, or it can 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 can be used to implement the teachings of the disclosure as described herein.
[0181] 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 in a manner that minimizes risks from unauthorized or unintended access or use. Additionally, users should be given the opportunity to opt in or opt out of collection of personally identifiable information data.
[0182] The foregoing discussion merely describes some exemplary embodiments of the present disclosure. Various modifications can be made to these embodiments without departing from the spirit and scope of the present disclosure.
Claims
1. A method for wireless communication by a user equipment (UE), the method comprising: determining a projected resource need for uplink wireless communication, the projected resource need for uplink wireless communication being determined with a machine learning (ML) model trained according to historical resource needs for uplink wireless communication by one or more UEs; sending, to a base station (BS), a resource request message including an indication of the projected resource need for uplink wireless communication; and identifying a resource grant including granted resources corresponding to the projected resource need for uplink wireless communication.
2. The method of claim 1, wherein the projected resource need for uplink wireless communication includes a predicted buffer size.
3. The method of claim 1, wherein the projected resource need for uplink wireless communication includes a predicted size of a projected data packet and a predicted arrival time of the projected data packet in a buffer.
4. The method of claim 3, the method further comprising: identifying an actual size of the projected data packet; and determining an error in the projected resource need for uplink wireless communication based on a comparison of the predicted size of the projected data packet to the actual size of the projected data packet in the buffer.
5. The method of claim 3, the method further comprising: identifying an actual arrival of the projected data packet in the buffer; and determining an error in the projected resource need for uplink wireless communication based on a comparison of the predicted arrival time of the projected data packet in the buffer to the actual arrival time of the projected data packet in the buffer. determining the projected resource need for uplink wireless communication in response to an arrival of a current data packet in a buffer. providing input to the ML model based on one or more of a current packet size and a current packet arrival time in a buffer to determine the projected resource need for uplink wireless communication.
8. The method of claim 1, the method further comprising:
6. The method of claim 1, further comprising: detecting an arrival of a current data packet in a buffer; 7. The method of claim 1, further comprising: determining a size of the current data packet; determining a time between the arrival of the current data packet in the buffer and an arrival of a previous data packet in the buffer; and providing the size of the current data packet and the time between the arrival of the current data packet and the previous data packet as input to the ML model to determine the projected resource need for uplink wireless communication.
9. The method of claim 1, wherein the ML model includes a recurrent neural network (RNN).
10. The method of claim 9, wherein the RNN includes a long short-term memory network. 11. The method of claim 1, wherein the historical resource demand for uplink wireless communications comprises actual sizes of transmitted data packets and actual arrival times of the transmitted data packets in a buffer.
12. The method of claim 1, wherein the resource request message comprises one or more of: a buffer status report (BSR) message, a scheduling request (SR) message, and a medium access control (MAC) control element (CE) message.
13. The method of claim 12, wherein the resource request message is transmitted during an SR opportunity.
14. The method of claim 1, wherein the indication of the projected resource demand for uplink wireless communications transmitted to the BS comprises a predicted buffer status report value.
15. The method of claim 1, wherein the resource request message transmitted to the BS comprises a time at which the projected resource demand is needed.
16. The method of claim 15, wherein the time at which the projected resource demand is needed comprises an earliest possible grant time and a latest acceptable grant time.
17. The method of claim 1, further comprising: determining a confidence level of the projected resource demand for uplink wireless communications.
18. The method of claim 17, further comprising: transmitting the resource request message in response to the confidence level exceeding a threshold confidence level.
19. The method of claim 17, wherein the resource request message comprises the confidence level of the projected resource demand.
20. The method of claim 1, wherein the projected resource demand for uplink wireless communications is determined, and the resource request message is transmitted to the BS based on a preconfigured periodicity.
21. The method of claim 1, wherein the resource request message is transmitted to the BS based on a triggering event.
22. The method of claim 21, wherein the trigger event comprises: determining that a difference between a predicted buffer size and an actual buffer size exceeds a threshold.
23. The method of claim 21, wherein the trigger event comprises: determining that a predicted buffer size exceeds a threshold.
24. The method of claim 21, wherein the trigger event comprises: determining that a confidence level of the projected resource demand for uplink wireless communications exceeds a threshold.
25. The method of claim 21, wherein the trigger event comprises: determining that a current grant fails to satisfy a latency requirement of predicted future latency-sensitive traffic.
26. The method of claim 21, wherein the trigger event comprises: determining excess resources or excess padding bits in a current grant.
27. The method of claim 1, the method further comprising: determining a difference between the projected resource demand for uplink wireless communications and an actual resource demand for uplink wireless communications; and initiating retraining of the ML model when the difference between the projected resource demand and the actual resource demand exceeds a threshold.
28. The method of claim 1, wherein the resource grant comprises a conditional multi- grant, the conditional multi-grant comprising a plurality of grants and a plurality of grant times corresponding to the plurality of grants.
29. A user equipment (UE) comprising one or more processors configured to perform the method of any of claims 1-28.
30. A non-transitory machine-readable medium having executable instructions for causing one or more processing units to perform the method of any of claims 1-28.
31. A method for wireless communication resource assignment by a base station (BS), the method comprising: identifying historical resource needs for uplink wireless communications of a user equipment (UE); training a machine learning model to determine projected resource needs for uplink wireless communications of the UE; sending the ML model to the UE; identifying, in a resource request message, an indication of projected resource needs for uplink wireless communications of the UE; and granting resources to the UE based on the projected resource needs for wireless communications of the UE.
32. The method of claim 31, wherein the ML model comprises a recurrent neural network (RNN).
33. The method of claim 32, wherein the RNN comprises a long short-term memory network.
34. The method of claim 31, wherein the resource request message comprises one or more of: a buffer status report (BSR) message, a scheduling request (SR) message, and a medium access control (MAC) control element (CE) message.
35. The method of claim 31, wherein the historical resource needs for uplink wireless communications comprise actual sizes of transmitted data packets and actual arrival times of the transmitted data packets in a buffer.
36. The method of claim 31, wherein the indication of the projected resource needs for uplink wireless communications comprises a predicted buffer status report (BSR).
37. The method of claim 36, wherein the predicted BSR is received with an old-fashioned BSR.
38. The method of claim 37, the method further comprising: determining overall network resource utilization; and granting the resources to the UE based on the overall network resource utilization based on the predicted BSR instead of the old-fashioned BSR.
39. The method of claim 37, wherein the predicted BSR is received with a confidence level of the predicted BSR, and the method further comprising: determining that the confidence level of the predicted BSR exceeds a threshold; and granting the resources to the UE based on the confidence level exceeding the threshold based on the predicted BSR instead of the old-fashioned BSR.
40. The method of claim 31, wherein the indication of the projected resource needs for uplink wireless communications comprises a time at which the projected resource needs are needed, and the resources are granted to the UE based on the time at which the projected resource needs are needed.
41. The method of claim 40, wherein the time at which the projected resource needs are needed comprises an earliest possible grant time and a latest acceptable grant time.
42. The method of claim 31, the method further comprising: identifying an updated historical resource demand for uplink wireless communications of the UE, the updated historical resource demand corresponding to a prediction error; and re-training the ML model based on the updated historical resource demand for uplink wireless communications of the UE.
43. The method of claim 30, wherein the resources granted to the UE comprise a plurality of grants and a plurality of grant times corresponding to the plurality of grants.
44. The method of claim 31, wherein the resources granted to the UE comprise a plurality of grants and a plurality of grant times corresponding to the plurality of grants.
45. A base station (BS) comprising one or more processors configured to perform the method of any one of claims 31-43.
46. A non-transitory machine-readable medium having executable instructions for causing one or more processing units to perform the method of any one of claims 31-43.