Uplink augmented reality scheduling
By adopting the combination of enhanced CG scheduling scheme and dynamic grant in wireless communication systems, combined with wake-up signals, the resource delay and delay problems in burst services are solved, efficient uplink resource scheduling is achieved, and the system is improved Flexibility and resource utilization.
Patent Information
- Application Number
- CN202380040716.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-05-23
- Filing Date
- 2023-05-02
- Publication Date
- 2024-12-31
AI Technical Summary
When existing wireless communication systems deal with burst services, especially extended reality (XR) services, it is difficult to effectively schedule uplink resources, resulting in resource delay and delay problems, and dynamic grant (DG) scheduling has high cost and low efficiency. The problem.
Adopt an enhanced configuration grant (CG) scheduling scheme, by sending data through physical uplink shared channel (PUSCH) within CG timing, combined with dynamic grant (DG) scheduling, use wake-up signal (WUS) to reduce resource delay and improve scheduling flexibility to support burst business.
It realizes high throughput and low latency for burst services, reduces the demand for control signaling, improves resource usage efficiency, and reduces power consumption.
Smart Images

Figure CN119234458A_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims the benefit of and priority to U.S. patent application Ser. No. 17 / 664,583, filed May 23, 2022, which is hereby incorporated by reference herein. Background Art Technical Field
[0003] Aspects of the present disclosure relate to wireless communications, and more particularly to techniques for scheduling resources for uplink (UL) traffic, such as extended reality (XR) UL traffic.
[0004] Related technologies
[0005] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, broadcasts or other similar types of services. These wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available wireless communication system resources.
[0006] Although wireless communication systems have made tremendous technical progress over the years, challenges still exist. For example, complex and dynamic environments can still attenuate or block signals between wireless transmitters and wireless receivers. Therefore, there is a continuous desire to improve the technical performance of wireless communication systems, including, for example: improving the speed and data carrying capacity of communications, improving the efficiency of using shared communication media, reducing the power used by transmitters and receivers when performing communications, improving the reliability of wireless communications, avoiding redundant transmission and / or reception and related processing, improving the coverage area of wireless communications, increasing the number and types of devices that can access wireless communication systems, increasing the ability of different types of devices to communicate with each other, increasing the number and types of wireless communication media available for use, etc. Therefore, there is a need to further improve wireless communication systems to overcome the above-mentioned technical challenges and other challenges. Summary of the invention
[0007] One aspect provides a method for wireless communication by a user equipment (UE). The method includes: receiving one or more configuration grant (CG) configurations from a network entity, each configuration grant (CG) configuration defining at least one CG opportunity within a data period; obtaining services in one or more bursts; and sending the services to the network entity in multiple physical uplink shared channels (PUSCHs) within the data period.
[0008] On the other hand, a method for wireless communication by a network entity is provided. The method includes: sending one or more CG configurations to a UE, each CG configuration defining at least one CG opportunity within a data period; and monitoring uplink services from the UE in multiple PUSCHs within the data period.
[0009] Other aspects provide: an apparatus operable to, configured to, or otherwise adapted to perform any one or more of the foregoing methods and / or those described elsewhere herein; a non-transitory computer-readable medium comprising instructions that, when executed by a processor of the apparatus, cause the apparatus to perform the foregoing methods and those described elsewhere herein; a computer program product embodied on a computer-readable storage medium comprising code for performing the foregoing methods and those described elsewhere herein; and / or an apparatus comprising components for performing the foregoing methods and those described elsewhere herein. By way of example, an apparatus may include a processing system, a device having a processing system, or a processing system cooperating through one or more networks.
[0010] For purposes of illustration, the following description and drawings set forth certain features. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The accompanying drawings depict certain features of the aspects described herein and should not be considered to limit the scope of the disclosure.
[0012] Figure 1 An example wireless communication network is depicted.
[0013] Figure 2 An example disaggregated base station architecture is depicted.
[0014] Figure 3 Aspects of an example base station and example user equipment are depicted.
[0015] Figure 4A , Figure 4B , Figure 4C and Figure 4D Various example aspects of data structures for a wireless communication network are described.
[0016] Figure 5 Dynamic scheduling and configuration grant (CG) scheduling for uplink (UL) traffic are depicted.
[0017] Figure 6 Example UL traffic delivery is depicted.
[0018] Figure 7 Depicted are example downlink control information (DCI) supporting multiple contiguous physical uplink shared channels (PUSCHs) per slot.
[0019] Fig. 8A and Figure 8B Depicted is an example DCI supporting multiple PUSCHs for single and multiple transmission and reception points (TRPs).
[0020] Fig. 9 Depicted is an example timing diagram for dynamic scheduling of multiple PUSCHs for extended reality (XR) traffic.
[0021] Fig.10 Depicted is a call flow diagram for example communications between a UE and a network entity in accordance with aspects of the present disclosure.
[0022] Fig.11A and Fig. 11B Depicted are multiple PUSCH scheduling for XR traffic within a data period in accordance with aspects of the present disclosure.
[0023] Fig.12 A combination of configuration grant (CG) and dynamic scheduling for XR traffic in accordance with aspects of the present disclosure is depicted.
[0024] Fig.13 A and Fig.13 B depicts a periodic schedule with multiple configuration grant (CG) opportunities for XR traffic according to aspects of the present disclosure.
[0025] Fig.14 Multiple PUSCH scheduling with wake-up signaling (WUS) for XR traffic in accordance with aspects of the present disclosure is depicted.
[0026] Fig.15 Depicted are tables describing various schemes for scheduling XR traffic in accordance with aspects of the present disclosure.
[0027] Fig.16 A method for wireless communication is described.
[0028] Fig.17 A method for wireless communication is described.
[0029] Fig.18 Aspects of an example communications device are depicted.
[0030] Fig.19 Aspects of an example communications device are depicted. DETAILED DESCRIPTION
[0031] Aspects of the present disclosure provide apparatus, methods, processing systems, and computer-readable media for scheduling resources for uplink (UL) traffic, such as uplink extended reality (XR) scheduling.
[0032] XR traffic is characterized by a mix of gesture and video traffic to or from XR devices (e.g., headsets). This traffic is characterized by varying video frame sizes over time and bursty (quasi-periodic) packet arrivals at varying delays (applied jitter).
[0033] In current wireless systems (e.g., 5G New Radio (NR)), network entities can periodically schedule radio resources via configuration grants (CGs). Resources within CGs allow user equipment (UEs) to send data to network entities within known time frames, eliminating the need for expensive and inefficient control scheduling associated with dynamic resource scheduling and dynamic grants (DGs).
[0034] However, 5G support for extended and augmented reality (XR / AR) has increased the need for uplink (UL) transmission of bursty traffic. As noted above, such traffic may have data packets of widely varying sizes, and each packet may have its own associated latency. Therefore, the latency and cost benefits associated with CG scheduling may be reduced because the periodicity of the CG may not be configured to optimally transmit bursty traffic with unpredictable variability.
[0035] Various aspects of the present disclosure provide techniques for enhancing CG-based resource scheduling for bursty traffic. In some aspects, one or more CG configurations may utilize physical uplink shared channel (PUSCH) transmissions within CG opportunities to reduce UL transmission overhead. In some aspects, the CG configuration may be implemented with dynamic grant (DG)-based scheduling to effectively schedule data sent between CG opportunities. In some aspects, the CG configuration may utilize a wake-up signal (WUS) to mitigate resource delays (i.e., jitter).
[0036] The enhanced CG scheduling scheme proposed in this paper can address the variability in bursty traffic, thereby allowing higher throughput and minimizing latency by increasing scheduling flexibility.
[0037] Introduction to wireless communication networks
[0038] The techniques and methods described herein can be used in various wireless communication networks. Although various aspects may be described herein using terms commonly associated with 3G, 4G and / or 5G wireless technologies, various aspects of the present disclosure may also be applicable to other communication systems and standards not explicitly mentioned herein.
[0039] Figure 1 An example of a wireless communication network 100 is depicted in which various aspects described herein may be implemented.
[0040] In general, the wireless communication network 100 includes various network entities (alternatively, network elements or network nodes). A network entity is typically a communication device and / or a communication function performed by a communication device (e.g., user equipment (UE), base station (BS), component of a BS, server, etc.). For example, various functions of a network and various devices associated with and interacting with the network may be considered network entities. In addition, the wireless communication network 100 includes ground aspects, such as ground-based network entities (e.g., BS 102), and non-ground aspects, such as satellites 140 and aircraft 145, which may include airborne network entities (e.g., one or more BSs) capable of communicating with other network elements (e.g., ground BSs) and user equipment.
[0041] In the depicted example, the wireless communication network 100 includes a BS 102, a UE 104, and one or more core networks (such as an evolved packet core (EPC) 160 and a 5G core (5GC) network 190) that interoperate to provide communication services over various communication links (including wired and wireless links).
[0042] Figure 1 Various example UEs 104 are depicted, which may more generally include: a cellular phone, a smart phone, a Session Initiation Protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player, a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, an Internet of Things (IoT) device, an Always-On (AON) device, an edge processing device, or other similar devices. UE 104 may also be more generally referred to as a mobile device, a wireless device, a wireless communication device, a station, a mobile station, a subscriber station, a mobile subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a remote device, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, and others.
[0043] BS 102 wirelessly communicates with (e.g., transmits signals to or receives signals from) UE 104 via communication link 120. Communication link 120 between BS 102 and UE 104 may include uplink (UL) (also referred to as a reverse link) transmissions from UE 104 to BS 102 and / or downlink (DL) (also referred to as a forward link) transmissions from BS 102 to UE 104. In various aspects, communication link 120 may employ multiple-input multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity.
[0044] BS 102 may generally include: NodeB, enhanced NodeB (eNB), next generation enhanced NodeB (ng-eNB), next generation NodeB (gNB or gNodeB), access point, base transceiver, radio base station, radio transceiver, transceiver function, transmission and reception point, and / or other. Each of BS 102 may provide communication coverage for a corresponding geographic coverage area 110, which may sometimes be referred to as a cell, and may overlap in some cases (e.g., a small cell 102' may have a coverage area 110' that overlaps with the coverage area 110 of a macro cell). For example, a BS may provide communication coverage for a macro cell (covering a relatively large geographic area), a pico cell (covering a relatively small geographic area, such as a stadium), a femto cell (relatively small geographic area (e.g., a home)), and / or other types of cells.
[0045] Although BS 102 is depicted as a single communication device in various aspects, BS 102 may be implemented in various configurations. For example, one or more components of the base station may be decomposed, including a central unit (CU), one or more distributed units (DU), one or more radio units (RU), a near real-time (near RT) RAN intelligent controller (RIC), or a non-real-time (non-RT) RIC, to name a few examples. In another example, various aspects of the base station may be virtualized. More generally, a base station (e.g., BS 102) may include components located at a single physical location or components located at various physical locations. In examples where the base station includes components located at various physical locations, the various components may each perform a function such that the various components together implement functions similar to those of a base station located at a single physical location. In some aspects, a base station including components located at various physical locations may be referred to as a decomposed radio access network architecture (such as an open RAN (O-RAN) or virtualized RAN (VRAN) architecture). Figure 2 An example decomposed base station architecture is depicted and described.
[0046] Different BSs 102 within the wireless communication network 100 may also be configured to support different radio access technologies (such as 3G, 4G, and / or 5G). For example, a BS 102 configured for 4G LTE (collectively referred to as the Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) may interface with the EPC 160 via a first backhaul link 132 (e.g., an S1 interface). A BS 102 configured for 5G (e.g., 5G NR or Next Generation RAN (NG-RAN)) may interface with the 5GC 190 via a second backhaul link 184. The BSs 102 may communicate with each other directly or indirectly (e.g., via the EPC 160 or the 5GC 190) over a third backhaul link 134 (e.g., an X2 interface), which may be wired or wireless.
[0047] The wireless communication network 100 may subdivide the electromagnetic spectrum into various categories, frequency bands, channels, or other characteristics. In some aspects, the subdivision is provided based on wavelength and frequency, where frequency may also be referred to as a carrier, subcarrier, channel, tone, or subband. For example, 3GPP currently defines frequency range 1 (FR1) as including 410 MHz-7125 MHz, which is often (interchangeably) referred to as "below 6 GHz". Similarly, 3GPP currently defines frequency range 2 (FR2) as including 24,250 MHz-52,600 MHz, which is sometimes (interchangeably) referred to as "millimeter wave" ("mmW" or "mmWave"). A base station (e.g., a mmWave base station such as BS 180) configured to communicate using mmWave / near mmWave radio bands may utilize beamforming (e.g., 182) with a UE (e.g., 104) to improve path loss and range.
[0048] The communication link 120 between the BS 102 and, for example, the UE 104 may be through one or more carriers, which may have different bandwidths (e.g., 5 MHz, 10 MHz, 15 MHz, 20 MHz, 100 MHz, 400 MHz, and / or other MHz) and may be aggregated in various aspects. The carriers may or may not be adjacent to each other. The allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated for DL compared to UL).
[0049] Communications using higher frequency bands may have higher path loss and shorter range than communications at lower frequencies. Therefore, some base stations (e.g. Figure 1180) may utilize beamforming 182 with UE 104 to improve path loss and distance. For example, BS 180 and UE 104 may each include multiple antennas (such as antenna elements, antenna panels and / or antenna arrays) to facilitate beamforming. In some cases, BS 180 may send beamformed signals to UE 104 in one or more transmit directions 182'. UE 104 may receive beamformed signals from BS 180 in one or more receive directions 182". UE 104 may also send beamformed signals to BS 180 in one or more transmit directions 182". BS 180 may also receive beamformed signals from UE 104 in one or more receive directions 182'. BS 180 and UE 104 may then perform beam training to determine the best receive and transmit directions for each of BS 180 and UE 104. It is noteworthy that the transmit direction and receive direction of BS 180 may be the same or different. Similarly, the transmit direction and receive direction of UE 104 may be the same or different.
[0050] Wireless communication network 100 also includes Wi-Fi AP 150 that communicates with Wi-Fi station (STA) 152 via communication link 154 in, for example, the 2.4 GHz and / or 5 GHz unlicensed spectrum.
[0051] Certain UEs 104 may communicate with each other using a device-to-device (D2D) communication link 158. The D2D communication link 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), a physical sidelink control channel (PSCCH), and / or a physical sidelink feedback channel (PSFCH).
[0052] The EPC 160 may include various functional components, including: a mobility management entity (MME) 162, other MMEs 164, a serving gateway 166, a multimedia broadcast multicast service (MBMS) gateway 168, a broadcast multicast service center (BM-SC) 170, and / or a packet data network (PDN) gateway 172, such as in the depicted example. The MME 162 may communicate with a home subscriber server (HSS) 174. The MME 162 is a control node that handles signaling between the UE 104 and the EPC 160. In general, the MME 162 provides bearer and connection management.
[0053] Typically, user Internet Protocol (IP) packets are delivered through the Serving Gateway 166, which itself is connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation and other functions. The PDN Gateway 172 and the BM-SC 170 are connected to IP services 176, which may include, for example, the Internet, an intranet, an IP Multimedia Subsystem (IMS), a Packet Switched (PS) streaming media service, and / or other IP services.
[0054] The BM-SC 170 may provide functionality for MBMS user service configuration and delivery. The BM-SC 170 may serve as an entry point for content provider MBMS delivery, may be used to authorize and initiate MBMS bearer services within a public land mobile network (PLMN), and / or may be used to schedule MBMS delivery. The MBMS Gateway 168 may be used to distribute MBMS services to BSs 102 belonging to a multicast broadcast single frequency network (MBSFN) area broadcasting a specific service, and / or may be responsible for session management (start / stop) and for collecting eMBMS related charging information.
[0055] 5GC 190 may include various functional components, including: access and mobility management function (AMF) 192, other AMF 193, session management function (SMF) 194 and user plane function (UPF) 195. AMF 192 may communicate with unified data management (UDM) 196.
[0056] AMF 192 is a control node that handles signaling between UE 104 and 5GC 190. AMF 192 provides, for example, Quality of Service (QoS) flow and session management.
[0057] Internet Protocol (IP) packets are delivered through UPF 195, which connects to IP Services 197 and provides IP address allocation for UEs and other functions for 5GC 190. IP Services 197 may include, for example, the Internet, Intranet, IMS, PS streaming services, and / or other IP services.
[0058] In various aspects, a network entity or network node may be implemented as a converged base station, a decomposed base station, a component of a base station, an integrated access and backhaul (IAB) node, a relay node, a sidelink node, to name a few examples.
[0059] Figure 2An example disaggregated base station 200 architecture is depicted. The disaggregated base station 200 architecture may include one or more central units (CUs) 210 that may communicate directly with a core network 220 via a backhaul link, or indirectly with the core network 220 through one or more disaggregated base station units, such as a near real-time (near-RT) RAN intelligent controller (RIC) 225 via an E2 link, or a non-real-time (non-RT) RIC 215 associated with a service management and orchestration (SMO) framework 205, or both. The CU 210 may communicate with one or more distributed units (DUs) 230 via respective midhaul links, such as an F1 interface. The DU 230 may communicate with one or more radio units (RUs) 240 via respective fronthaul links. The RU 240 may communicate with respective UEs 104 via one or more radio frequency (RF) access links. In some implementations, a UE 104 may be served simultaneously by multiple RUs 240.
[0060] Each of the units (e.g., CU 210, DU 230, RU 240, and near-RT RIC 225, non-RT RIC 215, and SMO framework 205) may include or be coupled to one or more interfaces configured to receive or send signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of the units or an associated processor or controller that provides instructions to the communication interface of the unit may be configured to communicate with one or more of the other units via a transmission medium. For example, a unit may include a wired interface configured to receive or send signals to one or more of the other units via a wired transmission medium. Additionally or alternatively, a unit may include a wireless interface that may include a receiver, a transmitter, or a transceiver (such as a radio frequency (RF) transceiver) configured to receive or send signals, or both, to one or more of the other units on a wireless transmission medium.
[0061] In some aspects, CU 210 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented as having an interface configured to communicate signals with other control functions hosted by CU 210. CU210 may be configured to handle user plane functions (e.g., central unit-user plane (CU-UP)), control plane functions (e.g., central unit-control plane (CU-CP)), or a combination thereof. In some specific implementations, CU 210 may be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface (such as an E1 interface). As needed, CU 210 may be implemented to communicate with DU 230 for network control and signaling.
[0062] DU 230 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 240. In some aspects, DU 230 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) based at least in part on functional splits such as those defined by the 3rd Generation Partnership Project (3GPP). In some aspects, DU 230 may further host one or more low PHY layers. Each layer (or module) may be implemented with an interface that is configured to communicate signals with other layers (and modules) hosted by DU 230 or with control functions hosted by CU 210.
[0063] The lower layer functions may be implemented by one or more RUs 240. In some deployments, a RU 240 controlled by a DU 230 may correspond to a logical node that hosts RF processing functions or low PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional split (such as a lower layer functional split). In such an architecture, the RU 240 may be implemented to handle over-the-air (OTA) communications with one or more UEs 104. In some implementations, real-time and non-real-time aspects of control plane and user plane communications with the RU 240 may be controlled by the corresponding DU 230. In some scenarios, this configuration may enable the DU 230 and the CU 210 to be implemented in a cloud-based RAN architecture (such as a vRAN architecture).
[0064] The SMO framework 205 may be configured to support RAN deployment and configuration of non-virtualized network elements and virtualized network elements. For non-virtualized network elements, the SMO framework 205 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 205 may be configured to interact with a cloud computing platform (such as an open cloud (O-Cloud) 290) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements may include, but are not limited to, CU 210, DU 230, RU 240, and near-RT RIC 225. In some specific implementations, the SMO framework 205 may communicate with hardware aspects of the 4G RAN (such as an open eNB (O-eNB) 211) via an O1 interface. Additionally, in some specific implementations, the SMO framework 205 may communicate directly with one or more RU240 via an O1 interface. The SMO framework 205 may also include a non-RT RIC 215 configured to support the functionality of the SMO framework 205 .
[0065] The non-RT RIC 215 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 225. The non-RT RIC 215 may be coupled to or in communication with the near-RT RIC 225 (such as via an A1 interface). The near-RT RIC 225 may be configured to include logic functions that enable near-real-time control and optimization of RAN elements and resources via data collection and actions through an interface (such as via an E2 interface) that connects one or more CUs 210, one or more DUs 230, or both, and the O-eNB with the near-RT RIC 225.
[0066] In some implementations, in order to generate an AI / ML model to be deployed in the near-RT RIC 225, the non-RT RIC 215 may receive parameters or external enrichment information from an external server. Such information may be utilized by the near-RT RIC 225 and may be received from a non-network data source or from a network function at the SMO framework 205 or the non-RT RIC 215. In some examples, the non-RT RIC 215 or the near-RT RIC 225 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 215 may monitor long-term trends and patterns for performance and employ AI / ML models to perform corrective actions through the SMO framework 205 (such as via reconfiguration of O1) or via creation of RAN management policies (such as A1 policies).
[0067] Figure 3 Aspects of an example BS 102 and UE 104 are depicted.
[0068] In general, BS 102 includes various processors (e.g., 320, 330, 338, and 340), antennas 334a-334t (collectively 334), transceivers 332a-332t (collectively 332) including modulators and demodulators, and other aspects that enable wireless transmission of data (e.g., data source 312) and wireless reception of data (e.g., data sink 339). For example, BS 102 can transmit and receive data between BS 102 and UE 104. BS 102 includes a controller / processor 340 that can be configured to implement various functions described herein related to wireless communication.
[0069] In general, the UE 104 includes various processors (e.g., 358, 364, 366, and 380), antennas 352a-352r (collectively 352), transceivers 354a-354r (collectively 354) including modulators and demodulators, and other aspects that enable wireless transmission of data (e.g., retrieved from a data source 362) and wireless reception of data (e.g., provided to a data sink 360). The UE 104 includes a controller / processor 380 that can be configured to implement various functions described herein related to wireless communications.
[0070] Regarding example downlink transmissions, BS 102 includes a transmit processor 320 that can receive data from a data source 312 and control information from a controller / processor 340. The control information can be for a physical broadcast channel (PBCH), a physical control format indicator channel (PCFICH), a physical HARQ indicator channel (PHICH), a physical downlink control channel (PDCCH), a group common PDCCH (GC PDCCH), and / or others. In some examples, the data can be for a physical downlink shared channel (PDSCH).
[0071] The transmit processor 320 may process (e.g., encode and symbol map) data and control information to obtain data symbols and control symbols, respectively. The transmit processor 320 may also generate reference symbols, such as for a primary synchronization signal (PSS), a secondary synchronization signal (SSS), a PBCH demodulation reference signal (DMRS), and a channel state information reference signal (CSI-RS).
[0072] The transmit (TX) multiple-input multiple-output (MIMO) processor 330 may perform spatial processing (e.g., pre-decoding) on data symbols, control symbols, and / or reference symbols, where applicable, and may provide an output symbol stream to a modulator (MOD) in transceivers 332a to 332t. Each modulator in transceivers 332a-332t may process a corresponding output symbol stream to obtain an output sample stream. Each modulator may further process (e.g., convert to analog, amplify, filter, and up-convert) the output sample stream to obtain a downlink signal. The downlink signals from the modulators in transceivers 332a to 332t may be transmitted via antennas 334a to 334t, respectively.
[0073] To receive downlink transmissions, UE 104 includes antennas 352a-352r that can receive downlink signals from BS 102 and can provide received signals to demodulators (DEMODs) in transceivers 354a-354r, respectively. Each demodulator in transceivers 354a-354r can condition (e.g., filter, amplify, downconvert, and digitize) a corresponding received signal to obtain input samples. Each demodulator can further process the input samples to obtain received symbols.
[0074] A MIMO detector 356 may obtain received symbols from all demodulators in transceivers 354a-354r, perform MIMO detection on the received symbols if applicable, and provide detected symbols. A receive processor 358 may process (e.g., demodulate, deinterleave, and decode) the detected symbols, provide decoded data for the UE 104 to a data sink 360, and provide decoded control information to a controller / processor 380.
[0075] With respect to example uplink transmissions, the UE 104 also includes a transmit processor 364 that may receive and process data from a data source 362 (e.g., for a PUSCH) and control information from a controller / processor 380 (e.g., for a physical uplink control channel (PUCCH)). The transmit processor 364 may also generate reference symbols for reference signals (e.g., a sounding reference signal (SRS)). The symbols from the transmit processor 364 may be pre-decoded by a TX MIMO processor 366, if applicable, further processed by a modulator in the transceivers 354a-354r (e.g., for SC-FDM), and transmitted to the BS 102.
[0076] At BS 102, uplink signals from UE 104 may be received by antennas 334 a-334 t, processed by demodulators in transceivers 332 a-332 t, detected by MIMO detector 336 if applicable, and further processed by receive processor 338 to obtain decoded data and control information transmitted by UE 104. Receive processor 338 may provide decoded data to data sink 339 and decoded control information to controller / processor 340.
[0077] Memories 342 and 382 may store data and program codes for BS 102 and UE 104, respectively.
[0078] The scheduler 344 may schedule UEs for data transmission on the downlink and / or uplink.
[0079] In various aspects, the BS 102 may be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, "transmitting" may refer to various mechanisms for outputting data, such as outputting data from a data source 312, a scheduler 344, a memory 342, a transmit processor 320, a controller / processor 340, a TX MIMO processor 330, a transceiver 332a-332t, an antenna 334a-334t, and / or other aspects described herein. Similarly, "receiving" may refer to various mechanisms for obtaining data, such as obtaining data from an antenna 334a-334t, a transceiver 332a-332t, a RX MIMO detector 336, a controller / processor 340, a receive processor 338, a scheduler 344, a memory 342, and / or other aspects described herein.
[0080] In various aspects, the UE 104 may also be described as sending and receiving various types of data associated with the methods described herein. In these contexts, "sending" may refer to various mechanisms for outputting data, such as outputting data from a data source 362, a memory 382, a transmit processor 364, a controller / processor 380, a TX MIMO processor 366, a transceiver 354a-354t, an antenna 352a-352t, and / or other aspects described herein. Similarly, "receiving" may refer to various mechanisms for obtaining data, such as obtaining data from an antenna 352a-352t, a transceiver 354a-354t, a RX MIMO detector 356, a controller / processor 380, a receive processor 358, a memory 382, and / or other aspects described herein.
[0081] In some aspects, the processor may be configured to perform various operations (such as those associated with the methods described herein) and send (output) data to or receive (obtain) data from another interface configured to send or receive data, respectively.
[0082] Figure 4A , Figure 4B , Figure 4C and Figure 4D Describes a method for use in a wireless communication network such as Figure 1 Various aspects of the data structure of the wireless communication network 100).
[0083] Specifically, Figure 4A is a diagram 400 illustrating an example of a first subframe within a 5G (e.g., 5G NR) frame structure, Figure 4B is a diagram 430 illustrating an example of a DL channel within a 5G subframe, Figure 4C is a diagram 450 illustrating an example of a second subframe within a 5G frame structure, and Figure 4D FIG480 is a diagram illustrating an example of UL channels within a 5G subframe.
[0084] Wireless communication systems may utilize orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) on both the uplink and downlink. Such systems may also support half-duplex operation using time division duplex (TDD). OFDM and single carrier frequency division multiplexing (SC-FDM) can be used to maximize the system bandwidth (e.g., Figure 4B and Figure 4D The modulation symbols may be transmitted in the frequency domain using OFDM and / or in the time domain using SC-FDM.
[0085] The wireless communication frame structure may be frequency division duplex (FDD), where for a particular set of subcarriers, subframes within the set of subcarriers are dedicated to either DL or UL. The wireless communication frame structure may also be time division duplex (TDD), where for a particular set of subcarriers, subframes within the set of subcarriers are dedicated to both DL and UL.
[0086] exist Figure 4A and Figure 4C In the wireless communication frame structure, TDD is used, where D is DL, U is UL, and X is used flexibly between DL / UL. The UE can be configured with a time slot format (dynamically configured by DL control information (DCI) or semi-statically / statically configured by radio resource control (RRC) signaling) through the received time slot format indicator (SFI). In the depicted example, the 10ms frame is divided into 10 equally sized 1ms subframes. Each subframe may include one or more time slots. In some examples, each time slot may include 7 or 14 symbols, depending on the time slot format. The subframe may also include micro-time slots, which typically have fewer symbols than the entire time slot. Other wireless communication technologies may have different frame structures and / or different channels.
[0087] In certain aspects, the number of time slots within a subframe is based on the time slot configuration and the parameter set. For example, for time slot configuration 0, different parameter sets (μ) 0 to 5 allow for 1, 2, 4, 8, 16, and 32 time slots per subframe, respectively. For time slot configuration 1, different parameter sets 0 to 2 allow for 2, 4, and 8 time slots per subframe, respectively. Thus, for time slot configuration 0 and parameter set μ, there are 14 symbols / time slot and 2μ time slots / subframe. The subcarrier spacing and symbol length / duration are a function of the parameter set. The subcarrier spacing may be equal to 2 μ × 15kHz, where μ is parameter set 0 to 5. Thus, parameter set μ=0 has a subcarrier spacing of 15kHz, and parameter set μ=5 has a subcarrier spacing of 480kHz. The symbol length / duration is inversely related to the subcarrier spacing. Figure 4A , Figure 4B , Figure 4C and Figure 4D An example is provided for slot configuration 0 with 14 symbols per slot and parameter set μ=2 with 4 slots per subframe. The slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs.
[0088] like Figure 4A , Figure 4B , Figure 4C and Figure 4DAs depicted in , a resource grid can be used to represent a frame structure. Each time slot includes a resource block (RB) (also called a physical RB (PRB)) extending, for example, 12 consecutive subcarriers. The resource grid is divided into a plurality of resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.
[0089] like Figure 4A As illustrated, some REs carry Figure 1 and Figure 3 The RS may include a demodulation RS (DMRS) and / or a channel state information reference signal (CSI-RS) for channel estimation at the UE. The RS may also include a beam measurement RS (BRS), a beam refinement RS (BRRS), and / or a phase tracking RS (PT-RS).
[0090] Figure 4B Examples of various DL channels within a subframe of a frame are illustrated.The Physical Downlink Control Channel (PDCCH) carries DCI within one or more Control Channel Elements (CCEs), each CCE comprising, for example, nine RE Groups (REGs), each REG comprising, for example, four consecutive REs in an OFDM symbol.
[0091] The primary synchronization signal (PSS) may be in symbol 2 of a particular subframe of a frame. The PSS is transmitted by a UE (e.g., Figure 1 and Figure 3 104) is used to determine subframe / symbol timing and physical layer identification.
[0092] The Secondary Synchronization Signal (SSS) may be within symbol 4 of a particular subframe of a frame. The SSS is used by the UE to determine the physical layer cell identity group number and radio frame timing.
[0093] Based on the physical layer identifier and the physical layer cell identifier group number, the UE can determine the physical cell identifier (PCI). Based on the PCI, the UE can determine the location of the aforementioned DMRS. The physical broadcast channel (PBCH) carrying the master information block (MIB) can be logically grouped with the PSS and SSS to form a synchronization signal (SS) / PBCH block. The MIB provides the number of RBs in the system bandwidth and the system frame number (SFN). The physical downlink shared channel (PDSCH) carries user data, broadcast system information (such as system information blocks (SIBs)) that is not sent via the PBCH, and / or paging messages.
[0094] like Figure 4CAs illustrated, some REs carry DMRS for channel estimation at the base station (indicated as R for one particular configuration, but other DMRS configurations are possible). The UE may send DMRS for PUCCH and DMRS for PUSCH. The PUSCH DMRS may be sent, for example, in the first one or two symbols of the PUSCH. The PUCCH DMRS may be sent in different configurations depending on whether a short PUCCH or a long PUCCH is sent and depending on the specific PUCCH format used. The UE 104 may send a sounding reference signal (SRS). The SRS may be sent, for example, in the last symbol of a subframe. The SRS may have a comb structure, and the UE may send the SRS on one of the teeth of the comb. The SRS may be used by the base station for channel quality estimation to achieve frequency-dependent scheduling of the UL.
[0095] Figure 4D Examples of various UL channels within a subframe of a frame are illustrated. The PUCCH may be located at a position as indicated in one configuration. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicators (CQI), precoding matrix indicators (PMI), rank indicators (RI), and HARQ ACK / NACK feedback. The PUSCH carries data and may additionally be used to carry buffer status reports (BSRs), power headroom reports (PHRs), and / or UCI.
[0096] Aspects related to scheduling resources for UL XR
[0097] The enhanced CG scheduling scheme proposed in this paper can address the variability in bursty traffic, thereby allowing higher throughput and minimizing latency by increasing scheduling flexibility.
[0098] As noted above, in certain wireless communication systems (e.g., 5G NR wireless communication networks), the network may configure periodic uplink resources for the UE via a configuration grant (CG). The CG may reduce the latency and resource overhead associated with dynamically scheduling resources via a dynamic grant (DG) conveyed via downlink control information (DCI) in a physical downlink control channel (PDCCH).
[0099] Figure 5 Dynamic grant (DG) scheduling and CG scheduling are illustrated. DG may require PDCCH to schedule physical uplink shared channel (PUSCH) transmissions. Therefore, DG-based scheduling can result in additional packet transmission delays and increased resource usage. In contrast, uplink resources scheduled via CG occur periodically (called CG opportunities) without the need for control signaling, thereby eliminating the costs and delays associated with DG.
[0100] CG parameters are typically configured via RRC signaling, and activation of the grant is through RRC or L1 signaling. Typically, the periodicity and configured parameters (e.g., number of resource blocks (RBs), modulation and coding scheme (MCS), number of repetitions) are the same for all CG occasions in a CG configuration.
[0101] The uplink resource allocation of conventional CG scheduling may not be optimal for certain types of uplink traffic, such as those related to extended reality (XR) and augmented reality (AR). In the XR use case, certain types of uplink data (e.g., 3D estimates of human pose or necessary "pose" data) may be generated periodically, such as Figure 6 If the CG configuration matches the periodicity of data arrival, such as Figure 6 As shown in CG configuration 1, the CG resources may be very suitable for delivering UL services.
[0102] However, other types of business such as Figure 6 The AR services (e.g., video or other media) illustrated in the third timeline of FIG. 3 may have widely varying packet sizes and transmission delays. The variability in the number of packets per burst and the size of each packet within a burst may render the latency benefits of CG scheduling meaningless. For example, packets from one or more AR service bursts may require more UL resources than allocated in the first CG opportunity period. Therefore, according to some CG configurations, some of the AR services in the AR service will be delayed until the next CG opportunity, such as Figure 6 As illustrated in the fourth timeline for CG configuration 2.
[0103] In some cases, AR and XR services may also be sent in multiple service streams (streams) and configured with variable parameters and characteristics, which poses additional challenges to CG scheduled resources. In some cases, the CG scheduling configuration may not meet the data transmission requirements of multi-stream AR / XR services. In some cases, packets from one or more service bursts may have a periodicity that does not match the periodicity of the CG timing. Therefore, AR service bursts outside the CG timing within the CG cycle may be delayed to the next CG cycle. This delay may continue as long as the service and CG cycles do not match. In some cases, the resources used for actual service transmission may be out of sync with the resources used for transmission scheduled via the CG, causing transmission jitter. UL jitter may be caused by coding delays at the UE. Jitter can also make delays in UL transmissions difficult to remedy by periodic scheduling.
[0104] In some cases, dynamic grants can be used to schedule multiple PUSCHs (via a single DCI), such as Figure 7 exemplified. Figure 7The DCI can address some of the variability associated with bursty services (e.g., AR / XR services). For example, a UL burst with a long channel occupation time (COT) can be scheduled on multiple consecutive PUSCHs in multiple slots / minislots via a single DCI. As a result, UL bursts may require fewer expensive control signaling instances. In such cases, each transport block (TB) can be mapped to one slot or one minislot. Figure 7 The PUSCHs of the two RANs may have different lengths but are contiguous in the time domain and may share most parameters except a hybrid automatic repeat request (HARQ) process identifier, a redundancy version ID (RVID), a new data indicator (NDI), and a time domain resource allocation (TDRA).
[0105] like Fig. 8A As illustrated, in some cases, a single DCI may schedule multiple PUSCHs in a single time slot. In some cases, gaps between adjacent PUSCHs may be allowed, and there may be no maximum gap limits (except those derived from RRC parameters). TDRA may indicate PUSCHs in consecutive or non-consecutive time slots by configuring a start and length indicator value (SLIV), a mapping type, and a scheduling offset (e.g., K0 or K2) for each PUSCH in a row of the TDRA table. Figure 8B As illustrated, depending on UE capabilities, there may be one TB per timeslot in a single transmit and receive point (TRP) configuration, and one TB per TRP in a multiple TRP configuration.
[0106] In one example, a single DCI of DCI format DCI 0_1 may schedule multiple PUSCHs. In this case, frequency domain resource allocation (FDRA), MCS, scheduling request indicator (SRI), number of layers, precoding, antenna ports, and open-loop power control do not change and apply to all scheduled PUSCHs. A new TDRA table that supports multiple SLIVs (up to 8) may be defined. Discontinuous SLIVs are also supported. If multiple TBs are scheduled (e.g., between RVIDs 0 and 2), the format may have an NDI of one bit per TB and an RVID of one bit per TB, or if only one PUSCH is scheduled, the format may have two bits. The HARQ ID may apply to the first scheduled PUSCH. Each additional scheduled PUSCH may have an incremented HARQ ID.
[0107] In some cases, a single DCI scheduling multiple PUSCHs can be used to increase the efficiency of AR / XR scheduling. Fig. 9As illustrated, different bursts may arrive in different cycles. In the illustrated example, bursts 1 to 3 arrive in one data cycle, while burst 4 arrives in another cycle. As illustrated, the UE may request uplink resources for sending bursts 1 to 3 via a first SR. In response, the network may transmit a DCI (via PDCCH) that schedules multiple PUSCHs, thereby allowing the transmission of bursts 1 to 3. As shown, only one scheduling request (SR) and one PDCCH may be required to send bursts 1 to 3, thereby reducing the overall control signaling requirements associated with XR services that fall within a single XR data cycle. In this example, burst 4 arrives after the first XR data cycle, so an additional SR and DL grant (only for a single burst) are required.
[0108] In many cases, the packet size and number of packets per burst may vary. In such cases, the SR may be a request for resources including parameters (e.g., number of PUSCHs, MCS). For XR, the MCS may vary to accommodate the varying packet size.
[0109] Various aspects of the present disclosure provide techniques for enhancing CG scheduling for burst services (e.g., AR and XR services). In some aspects, one or more CG configurations may allow multiple PUSCH transmissions within a CG opportunity to reduce UL transmission overhead. In some aspects, CG and DG scheduling may be combined to efficiently schedule uplink services. In some aspects, the CG configuration may be combined with a wake-up signal (WUS) to reduce jitter in arriving packets. As noted above, the enhanced CG scheduling techniques proposed herein can address variability in AR / XR services, thereby allowing higher throughput and minimizing latency by increasing scheduling flexibility.
[0110] For reference Fig.10 The CG scheduling technique proposed herein can be understood by referring to the call flow diagram 1000, which shows the scheduling of uplink traffic from UE 1002 to network entity 1004. In some aspects, network entity 1002 can be relative to Figure 1 and Figure 3 BS 102 as depicted and described or with respect to Figure 2 An example of a decomposed base station is depicted and described. Similarly, UE 1004 may be relative to Figure 1 and Figure 3 An example of a UE 104 is depicted and described. However, in other aspects, the UE 104 may be another type of wireless communication device and the BS 102 may be another type of network entity or network node, such as those described herein.
[0111] At 1006, the network entity configures the UE with one or more CG configurations, each CG configuration defining at least one CG opportunity within the data period 1014. At 1008, the UE obtains (e.g., periodic uplink) services (e.g., XR services such as gestures and AR services) in one or more bursts. As illustrated, the UE sends uplink services in multiple PUSCHs within the data period based on the configuration (when monitored by the network entity).
[0112] According to certain aspects, as described above, one or more CG configurations (in Fig.10 In such a case, if Fig.11A As illustrated, when one or more data bursts arrive at the UE, the UE may send the data bursts in multiple PUSCHs of the first CG opportunity. In some cases, the UE may be configured with up to M PUSCHs for each CG opportunity. In some cases, the pre-configuration of various parameters (e.g., MCS, number of RBs, etc.) may vary across PUSCHs. In the case of little to no jitter, the network entity may place the CG opportunity close to the first arriving packet. Therefore, the UE may send the packet in the first PUSCH.
[0113] In some cases, when the UE does not intend to use all PUSCHs in the CG opportunity, the UE may transmit an indicator ("skip indicator") to notify the network entity so that the network entity may skip monitoring one or more future PUSCHs. Taking into account the network entity processing time, the UE may transmit the indicator before transmitting the scheduled skipped PUSCH. In some cases, the indicator may indicate the end of a burst of a cycle to the network entity.
[0114] exist Fig.11A In the example illustrated, the UE does not intend to use PUSCH M-1 and M. The UE transmits an indicator in PUSCH 3 at CG opportunity 1, allowing the network entity to skip monitoring these PUSCHs. If the UE does not transmit a skip indicator (e.g., PUSCH at CG opportunity 2), the network entity may monitor a maximum of M number of PUSCHs. In some cases, the indicator may indicate that more PUSCHs than initially activated may be used within the CG configuration (e.g., PUSCH>M). The extended PUSCH indicator may be preconfigured by the network entity.
[0115] In some cases, a request for a parameter change for future PUSCH may be piggybacked on such an indicator. The parameter change may include a change in CG parameters (e.g., MCS, number of RBs, number of PUSCHs per CG opportunity, etc.) in the same CG opportunity, the next CG opportunity, or a CG opportunity group. The UE may send a request for a parameter change of an indicator using sequence-based signaling (e.g., demodulation reference signaling (DMRS)), PDCCH (e.g., DCI), or PUSCH (e.g., medium access control (MAC) control element (CE)).
[0116] Fig. 11B The comparison between DG-based scheduling and scheduling using multiple PUSCH CG configurations is illustrated. Fig. 11B In the second timeline, a single DCI PUSCH reduces latency for the first three traffic bursts by eliminating control signaling for each PUSCH. In the third timeline, a multi-PUSCH CG configuration further reduces latency by completely eliminating control signaling.
[0117] According to certain aspects, one or more CG configurations sent by a network entity may be configured with multiple PUSCHs and sent together with a DG configuration. In many cases, a DG configuration implemented together with a CG configuration may further reduce the delay for retransmission.
[0118] Fig.12 The scheduling of UL data transmission using a combination of DG and CG scheduling is illustrated. Fig.12 In the first timeline of FIG. 1 , XR data traffic arrives in bursts (ie, bursts 1 to 4).
[0119] Fig.12 The second timeline of illustrates DG-based scheduling that the UE can use to send bursts 1 to 4 to the network entity. In this case, each burst requires control signaling (SR, PDCCH), thereby increasing latency and resource usage relative to other scheduling schemes.
[0120] Fig.12 The third timeline of illustrates a periodic resource scheduling that the UE can use to send bursts 1 to 4 to the network entity. In this case, the first CG opportunity can only send burst 1. The UE waits until the start of the second CG period to send bursts 2 and 3 in the second CG opportunity, and must wait until the start of the third CG period to send burst 4 in the third CG opportunity. Therefore, sending XR traffic only on CG configured resources may be particularly inefficient in terms of latency.
[0121] Fig.12The fourth timeline illustrates a combination of CG and DG based resource scheduling. In this case, burst 1 is transmitted at the first CG opportunity. However, the UE transmits an SR to request resources and receives a DG, allowing bursts 2 and 3 to be transmitted earlier, rather than waiting for the second CG opportunity. This allows burst 4 to be transmitted in the second CG opportunity, rather than waiting until the third CG opportunity. This combined scheduling scheme strikes a good balance due to the reduced control signaling compared to a pure dynamic scheduling configuration and the reduced latency compared to a pure periodic scheduling configuration.
[0122] like Fig.12 As illustrated in the fifth timeline of FIG, when a combined CG-based and DG-based resource scheduling scheme is used, the UE may also utilize a more data indicator. The more data indicator may tell the network entity that the UE has more uplink data and may use more PUSCH resources. Therefore, the more data indicator may effectively eliminate the need for a separate SR transmission. In other words, after detecting the more data indicator, the network entity may transmit a PDCCH with a dynamic grant without waiting for an SR from the UE. Therefore, control signaling and latency may be further reduced.
[0123] In some cases, the UE may transmit the (skip and / or more data) indicator via sequence-based signaling (e.g., DMRS) or via PUSCH (e.g., MAC CE). In some cases, the DMRS pattern may indicate different resource allocations. In some cases, PUSCH-based indicators may allow for larger indicator payloads. In some cases, the indicator may be based on the physical uplink control channel (PUCCH) if there is uplink control information (UCI) sent before the resources are needed.
[0124] According to certain aspects, a network entity may configure a UE with multiple (different) CG configurations. In some cases, a network entity may activate multiple such CG configurations. Thus, even though the CG period of each CG configuration may have only one CG opportunity, the UE may send burst traffic in multiple CG opportunities falling within a single data period.
[0125] like Fig.13 As illustrated in A, when one or more data bursts (i.e., bursts 1 to 3) arrive at the UE, the UE may send burst 1 in the first available CG opportunity (per CG configuration 1) in the data period. The UE may send bursts 2 and 3 in the second CG opportunity (per CG configuration 2) in the first data period. In the second data period, a second larger burst may be transmitted in the CG opportunities of all three CG configurations. This method can reduce latency by increasing the number of transmit resources available to the UE during the data period while eliminating the need for control signaling associated with dynamic signaling.
[0126] like Fig.13 As illustrated by the timeline in B, when configured with multiple CG configurations, the UE may transmit a skip indicator to notify the network entity that it may skip monitoring one or more CG opportunities. This may help save resources because one or more future CG opportunities may often be empty when sent. As noted above, the UE may transmit the indicator before transmitting the skipped CG opportunity in view of the network entity processing time. In the illustrated example, the UE transmits a skip indicator in the CG opportunity of CG configuration 2, indicating that it will skip the CG opportunity of CG configuration 3. If the UE does not transmit the skip indicator, the network entity may monitor all configured CG opportunities. In some cases, the indicator may indicate that more CG opportunities than initially activated can be used within the CG configuration. The extended CG opportunity indicator may be pre-configured by the network entity.
[0127] According to certain aspects, a wake-up signal (WUS) may be sent by the UE to move the CG opportunity closer to the start of the data period. The WUS may indicate to the network that the UE has data, and the network may adjust the period accordingly. In this way, WUS transmission may correct for latency associated with jitter. In some cases, WUS may reduce power consumption compared to transmission based on dynamic grants.
[0128] Fig.14 A WUS-based CG configuration (in the fourth timeline) is illustrated. Fig.14 The first three timelines are Fig.12 The first three timelines are mirrored and provided for comparison. Fig.14 In the fourth row of , the UE sends a WUS to the network entity at the beginning of the data period. Jitter may not be expected on the UL, but in this case, a WUS-based CG can be used to effectively move the CG opportunity closer to the arrival of the data in order to minimize latency. The UE may have a given window to send (according to) the CG, and the gNB may therefore monitor the WUS during this window. In some cases, the WUS may be sequence-based to reduce power consumption. In some cases, parameter changes for future CG opportunities may be piggybacked on the WUS. The UE may send the WUS using sequence-based signaling (e.g., demodulation reference signaling (DMRS)), PDCCH (e.g., DCI), UCI, or PUSCH (e.g., medium access control (MAC) control element (CE)).
[0129] Fig.15is a table summarizing the various parameters associated with various scheduling schemes, including the enhanced scheduling scheme proposed in this article. The first column indicates the scheduling scheme, the second column indicates the maximum number of SR / WUS signals, and the third column indicates the maximum number of PDCCHs, while the fourth column indicates the maximum number of PUSCHs. The fifth column indicates the maximum number of blind PUSCH decodings (performed at the network entity), the sixth column indicates the latency used for the scheduling scheme, and the seventh column indicates the power consumption used for each scheduling scheme. In the table, "M" defines the maximum number of WUS in the network entity monitoring window for each configuration. "N" defines the number of packets that can be sent per data period. "D" defines the number of PUSCHs that can be implemented in a multi-PUSCH configuration. "S" defines a CG configuration for multiple configurations. The relationship between M, N, D and S may depend on the service type and UE capabilities.
[0130] like Fig.15 As described, the enhanced UL resource scheduling techniques implemented according to various aspects of the present disclosure reduce latency and reduce power consumption for UL burst traffic. Specifically, the table shows how to use the enhanced techniques proposed herein to reduce (or eliminate) the number of SR and PDCCH transmissions with a corresponding reduction in latency, albeit at the expense of the number of blind decodings at the network entity (in some cases).
[0131] Example Operation of User Equipment
[0132] Fig.16 shows a method for use by a UE such as Figure 1 and Figure 3 Method 1600 for wireless communication with UE 104.
[0133] The method 1600 begins at step 1605 of receiving one or more CG configurations from a network entity, each CG configuration defining at least one CG opportunity within a data period. In some cases, the operation of this step refers to the following steps: Fig.18 The described circuits for receiving and / or codes for receiving may be or may be executed by the circuits and / or codes.
[0134] Method 1600 then proceeds to step 1610 of obtaining one or more bursts of (eg, periodic uplink) traffic. In some cases, the operation of this step is as described in reference to Fig.18 The described circuit for obtaining and / or code for obtaining, or can be executed by the circuit and / or the code.
[0135] Method 1600 then proceeds to step 1615, sending services to network entities in multiple PUSCHs during the data period. In some cases, the operation of this step refers to the following steps: Fig.18The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0136] In some aspects, one or more CG configurations indicate a maximum number of PUSCHs per CG occasion.
[0137] In some aspects, one or more CG configurations also indicate CG parameters for each of the PUSCHs.
[0138] In some aspects, at least some of the transmit parameters: vary across PUSCH opportunities within a CG period; or vary across different CG opportunities within a data period.
[0139] In some aspects, the method 1600 further includes sending an indication that the UE does not intend to use all of the maximum number of PUSCHs within the CG opportunity. In some cases, the operation of this step refers to as described in reference Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0140] In some aspects, the method 1600 further includes: sending an indication of at least one of: a change in one or more CG parameters for one or more subsequent PUSCHs; or a request for a change in one or more CG parameters for one or more subsequent PUSCHs. In some cases, the operation of this step refers to as described in reference Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0141] In some aspects, the request is for a change in one or more CG parameters for one or more subsequent PUSCHs in the same CG opportunity, a subsequent CG opportunity, or a subsequent CG opportunity group.
[0142] In some aspects, the change or request for change is indicated via at least one of: sequence-based signaling, UCI, or MAC-CE.
[0143] In some aspects, the method 1600 further includes sending an indication that the UE intends to use more than the maximum number of PUSCHs within the CG opportunity. In some cases, the operation of this step refers to as described in reference Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0144] In some aspects, sending services to a network entity in multiple PUSCHs within a data period includes: sending one or more PUSCHs within at least one CG opportunity; and sending one or more PUSCHs scheduled via one or more dynamic grants.
[0145] In some aspects, the method 1600 further includes sending at least one SR, wherein at least one of the dynamic grants is transmitted in response to the SR. In some cases, the operation of this step refers to as described in reference Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0146] In some aspects, the method 1600 further includes sending a more data indication that triggers the preconfigured PUSCH resources. In some cases, the operation of this step refers to the Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0147] In some aspects, the method 1600 further includes transmitting the PUSCH on at least some of the preconfigured PUSCH resources. In some cases, the operation of this step refers to the Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0148] In some aspects, the method 1600 further comprises sending an indication in one of the PUSCHs indicating the end of one of the data bursts. In some cases, the operation of this step refers to as described in reference to Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0149] In some aspects, the method 1600 further comprises sending a more data indication in one of the PUSCHs, wherein at least one of the dynamic grants is transmitted in response to the more data indication. In some cases, the operation of this step refers to as described in reference Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0150] In some aspects, the more data indicator is sent via at least one of: DMRS, MAC-CE, or UCI.
[0151] In some aspects, the one or more CG configurations include multiple CG configurations, each CG configuration having at least one associated CG opportunity within a data period.
[0152] In some aspects, sending traffic to network entities in multiple PUSCHs within a data period includes sending traffic within multiple CG opportunities, each CG opportunity being associated with one CG configuration among multiple CG configurations.
[0153] In some aspects, the method 1600 further includes sending a further data indication indicating that the UE intends to use at least one CG opportunity or CG configuration within the data period. In some cases, the operation of this step refers to as described in reference Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0154] In some aspects, the more data indicator also indicates a modification to one or more CG parameters.
[0155] In some aspects, the method 1600 further includes sending an indication that the UE does not intend to use at least one CG opportunity or CG configuration in the data period. In some cases, the operation of this step refers to as described in reference Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0156] In some aspects, the indication is sent via at least one of: sequence-based signaling, UCI, PUSCH, or MAC-CE.
[0157] In some aspects, the method 1600 further includes sending a WUS to the network entity at the beginning of the data period to indicate that the UE does intend to use at least one CG opportunity within the data period. In some cases, the operation of this step refers to the following steps: Fig.18 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0158] In some aspects, the WUS is sent at a fixed offset from the first PUSCH sent by the UE.
[0159] In some aspects, the WUS also indicates modifications to one or more CG parameters.
[0160] In some aspects, the WUS is sent via at least one of: sequence-based signaling, UCI, or MAC-CE.
[0161] In one aspect, method 1600 or any aspect related thereto may be performed by an apparatus such as Fig.18 The method 1600 is performed by a communication device 1800, which includes various components that are operable, configured, or adapted to perform the method 1600. The communication device 1800 is described in more detail below.
[0162] It should be noted that Fig.16 This is merely one example of a method, and other methods including fewer, additional, or alternative steps may be consistent with the present disclosure.
[0163] Example Operations of Network Entities
[0164] Fig.17 shows a method for use by network entities such as Figure 1 and Figure 3 BS 102 or as relative to Figure 2 A method 1700 of performing wireless communications with a decomposed base station is discussed.
[0165] Method 1700 begins with step 1705 of sending one or more CG configurations to the UE, each CG configuration defining at least one CG opportunity within a data period. In some cases, the operation of this step refers to the following reference Fig.19 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0166] The method 1700 then proceeds to the following step 1710, monitoring uplink traffic from the UE in a plurality of PUSCHs in a data period. In some cases, the operation of this step refers to the following steps. Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0167] In some aspects, one or more CG configurations indicate a maximum number of PUSCHs per CG occasion.
[0168] In some aspects, one or more CG configurations also indicate CG parameters for each of the PUSCHs.
[0169] In some aspects, at least some of the CG parameters: vary across PUSCH opportunities within CG periods; or vary across different CG opportunities within a data period.
[0170] In some aspects, the method 1700 further includes receiving an indication that the UE does not intend to use all of the maximum number of PUSCHs within the CG opportunity. In some cases, the operation of this step refers to as described in reference Fig.19 The described circuits for receiving and / or codes for receiving may be or may be executed by the circuits and / or codes.
[0171] In some aspects, the method 1700 further comprises monitoring for an indication of at least one of: a change in one or more CG parameters for one or more subsequent PUSCHs; or a request for a change in one or more CG parameters for one or more subsequent PUSCHs. In some cases, the operation of this step refers to as described in reference Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0172] In some aspects, the request is for a change in one or more CG parameters for one or more subsequent PUSCHs in the same CG opportunity, a subsequent CG opportunity, or a subsequent CG opportunity group.
[0173] In some aspects, the change or request for change is indicated via at least one of: sequence-based signaling, UCI, or MAC-CE.
[0174] In some aspects, the method 1700 further includes monitoring for an indication that the UE intends to use more than a maximum number of PUSCHs within a CG opportunity. In some cases, the operation of this step refers to the following steps: Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0175] In some aspects, monitoring uplink traffic from a UE in multiple PUSCHs within a data period includes: monitoring one or more PUSCHs within at least one CG opportunity; and monitoring one or more PUSCHs scheduled via one or more dynamic grants.
[0176] In some aspects, method 1700 further includes monitoring at least one SR. In some cases, the operation of this step is as described in reference Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0177] In some aspects, the method 1700 further includes sending at least one of the dynamic grants in response to the at least one SR. In some cases, the operation of this step refers to the operation of Fig.19 The described circuits for transmitting and / or codes for transmitting, or may be executed by the circuits and / or the codes.
[0178] In some aspects, the method 1700 further includes monitoring for a more data indication that triggers the preconfigured PUSCH resources. In some cases, the operation of this step refers to the Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0179] In some aspects, the method 1700 further includes monitoring the PUSCH on at least some of the preconfigured PUSCH resources. In some cases, the operation of this step refers to the Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0180] In some aspects, the method 1700 further comprises monitoring one of the PUSCHs for an indication of the end of one of the data bursts. In some cases, the operation of this step refers to the Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0181] In some aspects, the method 1700 further comprises monitoring a PUSCH in the PUSCH for a more data indication, wherein at least one of the dynamic grants is transmitted in response to the more data indication. In some cases, the operation of this step refers to as described in reference Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0182] In some aspects, the more data indicator is sent via at least one of: DMRS, MAC-CE, or UCI.
[0183] In some aspects, the one or more CG configurations include multiple CG configurations, each CG configuration having at least one associated CG opportunity within a data period.
[0184] In some aspects, monitoring uplink traffic from the UE in multiple PUSCHs within a data period includes monitoring the traffic in multiple CG occasions, each CG occasion being associated with one CG configuration of multiple CG configurations.
[0185] In some aspects, the method 1700 further includes monitoring for a further data indication indicating that the UE intends to use at least one CG opportunity or CG configuration within the data period. In some cases, the operation of this step refers to the following steps: Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0186] In some aspects, the more data indicator also indicates a modification to one or more CG parameters.
[0187] In some aspects, the method 1700 further includes monitoring an indication that the UE does not intend to use at least one CG opportunity or CG configuration within the data period. In some cases, the operation of this step refers to the following steps: Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0188] In some aspects, the indication is sent via at least one of: sequence-based signaling, UCI, PUSCH, or MAC-CE.
[0189] In some aspects, the method 1700 further includes monitoring a WUS from the UE at the beginning of the data period to indicate that the UE does intend to use at least one CG opportunity within the data period. In some cases, the operation of this step refers to the following Fig.19 The described circuits for monitoring and / or codes for monitoring may be or may be executed by the circuits and / or the codes.
[0190] In some aspects, the WUS also indicates modifications to one or more CG parameters.
[0191] In some aspects, the WUS is sent at a fixed offset from the first PUSCH sent by the UE.
[0192] In some aspects, the WUS is sent via at least one of: sequence-based signaling, UCI, or MAC-CE.
[0193] In one aspect, method 1700 or any aspect related thereto may be performed by an apparatus such as Fig.19 The method 1700 is performed by a communication device 1900, which includes various components that are operable, configured, or adapted to perform the method 1700. The communication device 1900 is described in more detail below.
[0194] It should be noted that Fig.17 This is merely one example of a method, and other methods including fewer, additional, or alternative steps may also be consistent with the present disclosure.
[0195] Example Communication Device
[0196] Fig.18 Depicted are aspects of an example communications device 1800. In some aspects, the communications device 1800 is user equipment, such as described above with respect to Figure 1 and Figure 3 UE 104 is described.
[0197] The communication device 1800 includes a processing system 1805 coupled to a transceiver 1855 (e.g., a transmitter and / or a receiver). The transceiver 1855 is configured to transmit and receive signals for the communication device 1800, such as the various signals described herein, via an antenna 1860. The processing system 1805 may be configured to perform processing functions for the communication device 1800, including processing signals received and / or to be transmitted by the communication device 1800.
[0198] The processing system 1805 includes one or more processors 1810. In various aspects, such as with respect to Figure 3As depicted, the one or more processors 1810 may represent one or more of the receive processor 358, the transmit processor 364, the TX MIMO processor 366, and / or the controller / processor 380. The one or more processors 1810 are coupled to the computer-readable medium / memory 1830 via the bus 1850. In certain aspects, the computer-readable medium / memory 1830 is configured to store instructions (e.g., computer-executable code) that, when executed by the one or more processors 1810, cause the one or more processors 1810 to perform operations with respect to the computer-readable medium / memory 1830. Fig.16 The described method 1600 or any aspect related thereto. It should be noted that references to a processor performing a function of the communication device 1800 may include one or more processors 1810 performing that function of the communication device 1800.
[0199] In the depicted example, computer readable medium / memory 1830 stores code (e.g., executable instructions), such as code for receiving 1835, code for obtaining 1840, and code for sending 1845. Processing of code for receiving 1835, code for obtaining 1840, and code for sending 1845 may cause communication device 1800 to perform operations relative to Fig.16 The described method 1600 or any aspect related thereto.
[0200] The one or more processors 1810 include circuits configured to implement (e.g., execute) code stored in the computer-readable medium / memory 1830, including circuits such as circuits for receiving 1815, circuits for obtaining 1820, and circuits for transmitting 1825. Processing performed by the circuits for receiving 1815, circuits for obtaining 1820, and circuits for transmitting 1825 may enable the communication device 1800 to perform operations relative to Fig.16 The described method 1600 or any aspect related thereto.
[0201] The various components of the communication device 1800 may be provided for performing Fig.16 The described means of method 1600 or any aspect thereof. For example, means for sending, transmitting, or outputting for sending may include Figure 3 The illustrated transceiver 354 and / or antenna 352 and / or Fig.18 The transceiver 1855 and antenna 1860 of the communication device 1800 in FIG. 1 may include Figure 3 The illustrated transceiver 354 and / or antenna 352 and / or Fig.18 The transceiver 1855 and antenna 1860 of the communication device 1800.
[0202] Fig.19 Various aspects of an example communications device 1900 are depicted. In some aspects, communications device 1900 is a network entity such as Figure 1 and Figure 3 BS 102 or as relative to Figure 2 The decomposed base station in question.
[0203] The communication device 1900 includes a processing system 1905 coupled to a transceiver 1955 (e.g., a transmitter and / or a receiver) and / or a network interface 1965. The transceiver 1955 is configured to transmit and receive signals for the communication device 1900 via an antenna 1960, such as the various signals described herein. The network interface 1965 is configured to transmit and receive signals for the communication device 1900 via a communication link, such as the various signals described herein with respect to Figure 2 The described backhaul link, midhaul link and / or fronthaul link are used to obtain and transmit signals for the communication device 1900. The processing system 1905 may be configured to perform processing functions for the communication device 1900, including processing signals received by and / or to be transmitted by the communication device 1900.
[0204] The processing system 1905 includes one or more processors 1910. In various aspects, such as with respect to Figure 3 As described, the one or more processors 1910 may represent one or more of the receive processor 338, the transmit processor 320, the TX MIMO processor 330, and / or the controller / processor 340. The one or more processors 1910 are coupled to the computer-readable medium / memory 1930 via the bus 1950. In some aspects, the computer-readable medium / memory 1930 is configured to store instructions (e.g., computer-executable code) that, when executed by the one or more processors 1910, cause the one or more processors 1910 to perform operations with respect to the computer-readable medium / memory 1930. Fig.17 The described method 1700 or any aspect related thereto. It should be noted that references to a processor of the communication device 1900 performing a function may include one or more processors 1910 of the communication device 1900 performing that function.
[0205] In the depicted example, computer readable medium / memory 1930 stores code (e.g., executable instructions), such as code for transmitting 1935, code for monitoring 1940, and code for receiving 1945. Processing of code for transmitting 1935, code for monitoring 1940, and code for receiving 1945 may cause communication device 1900 to perform operations relative to Fig.17 The described method 1700 or any aspect related thereto.
[0206] The one or more processors 1910 include circuits configured to implement (e.g., execute) code stored in the computer-readable medium / memory 1930, including circuits such as circuits for transmitting 1915, circuits for monitoring 1920, and circuits for receiving 1925. Processing performed by the circuits for transmitting 1915, the circuits for monitoring 1920, and the circuits for receiving 1925 may cause the communication device 1900 to perform operations such as those described above with respect to Fig.17 The described method 1700 or any aspect related thereto.
[0207] The various components of the communication device 1900 may be provided for performing the operations described in relation to Fig.17 Means for sending, transmitting, or outputting for sending may include: Figure 3 The illustrated transceiver 332 and / or antenna 334 and / or Fig.19 The transceiver 1955 and antenna 1960 of the communication device 1900 in FIG. 1 may include Figure 3 The illustrated transceiver 332 and / or antenna 334 and / or Fig.19 The transceiver 1955 and antenna 1960 of the communication device 1900.
[0208] Sample Clauses
[0209] Specific implementation examples are described in the following numbered clauses:
[0210] Clause 1: A method for wireless communication by a UE, the method comprising: receiving one or more CG configurations from a network entity, each CG configuration defining at least one CG opportunity within a data period; obtaining services in one or more bursts; and sending the services to the network entity in multiple PUSCHs within the data period.
[0211] Clause 2: A method according to clause 1, wherein the one or more CG configurations indicate a maximum number of PUSCHs per CG opportunity.
[0212] Clause 3: A method according to clause 2, wherein the one or more CG configurations also indicate CG parameters for each PUSCH in the PUSCH.
[0213] Clause 4: A method according to clause 3, wherein at least some of the transmission parameters: vary across PUSCH timings within a CG opportunity; or vary across different CG timings within a data period.
[0214] Clause 5: The method according to Clause 2 further comprises: sending an indication that the UE does not intend to use all of the maximum number of PUSCHs within the CG opportunity.
[0215] Clause 6: The method according to Clause 5 further includes: sending an indication of at least one of: a change in one or more CG parameters for one or more subsequent PUSCHs; or a request for a change in one or more CG parameters for one or more subsequent PUSCHs.
[0216] Clause 7: A method according to clause 6, wherein the request is for a change in one or more CG parameters for one or more subsequent PUSCHs in the same CG opportunity, a subsequent CG opportunity, or a subsequent CG opportunity group.
[0217] Clause 8: The method of clause 6, wherein the change or request for change is indicated via at least one of: sequence-based signaling, UCI, or MAC-CE.
[0218] Clause 9: The method according to Clause 2 further comprises: sending an indication that the UE intends to use more than the maximum number of PUSCHs within the CG opportunity.
[0219] Clause 10: A method according to Clause 2, wherein sending the service to the network entity in multiple PUSCHs within the data period includes: sending one or more PUSCHs within the at least one CG opportunity; and sending one or more PUSCHs scheduled via one or more dynamic grants.
[0220] Clause 11: The method of clause 10, further comprising: sending at least one SR, wherein at least one of the dynamic grants is transmitted in response to the SR.
[0221] Clause 12: A method as described in clause 10, the method further comprising: sending a more data indication that triggers pre-configured PUSCH resources; and sending PUSCH on at least some of the pre-configured PUSCH resources.
[0222] Clause 13: A method as described in clause 10, further comprising: sending an indication in one of the PUSCHs indicating an end of one of the data bursts.
[0223] Clause 14: The method of clause 10, further comprising: sending a more data indication in one of the PUSCHs, wherein at least one of the dynamic grants is transmitted in response to the more data indication.
[0224] Clause 15: The method of clause 14, wherein the more data indicator is sent via at least one of: DMRS, MAC-CE, or UCI.
[0225] Clause 16: A method according to any one of clauses 1 to 15, wherein the one or more CG configurations include multiple CG configurations, each CG configuration having at least one associated CG opportunity within the data period.
[0226] Clause 17: A method according to Clause 16, wherein sending the service to the network entity in multiple PUSCHs within the data period includes sending the service within multiple CG opportunities, each CG opportunity being associated with one CG configuration among the multiple CG configurations.
[0227] Clause 18: The method according to Clause 16 further comprises: sending a further data indication indicating that the UE intends to use at least one CG opportunity or CG configuration within the data period.
[0228] Clause 19: The method of clause 16, wherein the more data indicator further indicates a modification to one or more CG parameters.
[0229] Clause 20: The method according to Clause 16 further comprises: sending an indication that the UE does not intend to use at least one CG opportunity or CG configuration within the data period.
[0230] Clause 21: The method of clause 20, wherein the indication is sent via at least one of: sequence-based signaling, UCI, PUSCH, or MAC-CE.
[0231] Clause 22: A method according to any one of clauses 1 to 21, further comprising: sending a WUS to the network entity at the beginning of the data period to indicate that the UE does intend to use at least one CG opportunity within the data period.
[0232] Clause 23: A method as set forth in clause 22, wherein the WUS is sent at a fixed offset from a first PUSCH sent by the UE.
[0233] Clause 24: The method of clause 22, wherein the WUS further indicates a modification to one or more CG parameters.
[0234] Clause 25: The method of clause 22, wherein the WUS is sent via at least one of: sequence-based signaling, UCI, or AMAC-CE.
[0235] Clause 26: A method for wireless communication by a network entity, the method comprising: sending one or more CG configurations to a UE, each CG configuration defining at least one CG opportunity within a data period; and monitoring uplink traffic from the UE in multiple PUSCHs within the data period.
[0236] Clause 27: A method according to clause 26, wherein the one or more CG configurations indicate a maximum number of PUSCHs per CG opportunity.
[0237] Clause 28: A method according to clause 27, wherein the one or more CG configurations further indicate a CG parameter for each of the PUSCHs.
[0238] Clause 29: A method according to clause 28, wherein at least some of the CG parameters: vary across PUSCH within CG timings; or vary across different CG timings within a data period.
[0239] Clause 30: The method according to clause 27 further comprises: receiving an indication that the UE does not intend to use all PUSCHs of the maximum number of PUSCHs within the CG opportunity.
[0240] Clause 31: The method according to clause 30 further comprises: monitoring an indication of at least one of: a change in one or more CG parameters for one or more subsequent PUSCHs; or a request for a change in one or more CG parameters for one or more subsequent PUSCHs.
[0241] Clause 32: A method according to clause 31, wherein the request is for a change in one or more CG parameters for one or more subsequent PUSCHs in the same CG opportunity, a subsequent CG opportunity, or a subsequent CG opportunity group.
[0242] Clause 33: The method of clause 31, wherein the change or request for change is indicated via at least one of: sequence-based signaling, UCI, or MAC-CE.
[0243] Clause 34: The method according to clause 27 further comprises: monitoring an indication that the UE intends to use more than the maximum number of PUSCHs within a CG opportunity.
[0244] Clause 35: A method according to Clause 27, wherein monitoring uplink traffic from the UE in multiple PUSCHs within the data period includes: monitoring one or more PUSCHs within the at least one CG opportunity; and monitoring one or more PUSCHs scheduled via one or more dynamic grants.
[0245] Clause 36: The method of clause 35, further comprising: monitoring at least one SR; and sending at least one of the dynamic grants in response to the at least one SR.
[0246] Clause 37: A method as described in clause 35, the method further comprising: monitoring for a more data indication that triggers pre-configured PUSCH resources; and monitoring PUSCH on at least some of the pre-configured PUSCH resources.
[0247] Clause 38: The method of clause 35, further comprising: monitoring one of the PUSCHs for an indication of an end of one of the data bursts.
[0248] Clause 39: The method of clause 35, further comprising: monitoring one of the PUSCHs for a more data indication, wherein at least one of the dynamic grants is transmitted in response to the more data indication.
[0249] Clause 40: The method of clause 39, wherein the more data indicator is sent via at least one of: DMRS, MAC-CE, or UCI.
[0250] Clause 41: A method according to any one of clauses 26 to 40, wherein the one or more CG configurations include multiple CG configurations, each CG configuration having at least one associated CG opportunity within the data period.
[0251] Clause 42: A method according to clause 41, wherein monitoring the uplink service from the UE in multiple PUSCHs within the data period includes: monitoring the service in multiple CG occasions, each CG occasion being associated with one CG configuration among the multiple CG configurations.
[0252] Clause 43: The method according to Clause 41 further comprises: monitoring for further data indication indicating that the UE intends to use at least one CG opportunity or CG configuration within the data period.
[0253] Clause 44: The method of clause 41, wherein the more data indicator further indicates a modification to one or more CG parameters.
[0254] Clause 45: The method according to Clause 41 further comprises: monitoring an indication that the UE does not intend to use at least one CG opportunity or CG configuration within the data period.
[0255] Clause 46: The method of clause 45, wherein the indication is sent via at least one of: sequence-based signaling, UCI, PUSCH, or AMAC-CE.
[0256] Clause 47: A method according to any one of clauses 26 to 46, the method further comprising: monitoring a WUS from the UE at the beginning of the data period to indicate that the UE does intend to use at least one CG opportunity within the data period.
[0257] Clause 48: The method of clause 47, wherein the WUS further indicates a modification of one or more CG parameters.
[0258] Clause 49: A method as set forth in clause 47, wherein the WUS is transmitted at a fixed offset from a first PUSCH transmitted by the UE.
[0259] Clause 50: The method of clause 49, wherein the WUS is sent via at least one of: sequence-based signaling, UCI, or AMAC-CE.
[0260] Clause 51: An apparatus, the apparatus comprising: a memory comprising executable instructions; and a processor configured to execute the executable instructions and cause the apparatus to perform the method according to any one of clauses 1 to 50.
[0261] Clause 52: An apparatus comprising: means for performing the method according to any one of clauses 1 to 50.
[0262] Clause 53: A non-transitory computer readable medium comprising executable instructions which, when executed by a processor of an apparatus, cause the apparatus to perform the method of any of clauses 1 to 50.
[0263] Clause 54: A computer program product embodied on a computer readable storage medium, the computer readable storage medium comprising code for performing the method according to any one of clauses 1 to 50.
[0264] Additional considerations
[0265] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. The examples discussed herein do not limit the scope, applicability or aspects set forth in the claims. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. For example, without departing from the scope of the present disclosure, the functions and arrangements of the elements discussed may be changed. Each example may ignore, replace or add various procedures or components as appropriate. For example, the described method may be performed in a different order than the described order, and various actions may be added, omitted or combined. In addition, the features described for some examples may be combined in some other examples. For example, any number of aspects set forth herein may be used to implement a device or practice method. In addition, the scope of the present disclosure is intended to cover such devices or methods practiced using other structures, functions, or structures and functions that are supplementary or alternative to the various aspects of the present disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of the claims.
[0266] The various illustrative logic blocks, modules, and circuits described in conjunction with the present disclosure may be implemented or executed using a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any commercially available processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, a system on a chip (SoC), or any other such configuration.
[0267] As used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items (including single members). As an example, "at least one of a, b, or c" is intended to cover a, b, c, ab, ac, bc, and abc, as well as any combination with multiple identical elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).
[0268] As used herein, the term "determining" encompasses a wide variety of actions. For example, "determining" may include calculating, computing, processing, deriving, investigating, searching (e.g., searching in a table, a database, or another data structure), ascertaining, and the like. Also, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Additionally, "determining" may include resolving, selecting, choosing, establishing, and the like.
[0269] The method disclosed herein includes one or more actions for implementing the method. The method actions can be interchangeable with each other without departing from the scope of the claims. In other words, unless a specific order of actions is specified, the order and / or use of specific actions can be modified without departing from the scope of the claims. In addition, each operation of the method described above can be performed by any appropriate component that can perform the corresponding function. The component may include various hardware and / or software components and / or modules, including but not limited to circuits, application specific integrated circuits (ASICs) or processors.
[0270] The following claims are not intended to be limited to the various aspects shown herein, but should be granted the full scope consistent with the language of the claims. Within the claims, unless otherwise specified, reference to an element in the singular form is not intended to mean "one and only one", but "one or more". Unless otherwise specified, the term "some" refers to one or more. Any claim element is not interpreted according to the provisions of 35 U.S.C. § 112 (f) unless the element is explicitly stated using the phrase "member for...". All structural and functional equivalents of the elements throughout the various aspects described in this disclosure that are known or will be known later to a person of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, regardless of whether such disclosure is explicitly stated in the claims, anything disclosed herein is not intended to be disclosed to the public.
Claims
1. A method for wireless communication by a user equipment (UE), the method comprising: receiving one or more configuration grant (CG) configurations from a network entity, each configuration grant (CG) configuration defining at least one CG opportunity within a data period; as well as Obtaining one or more bursts of services; as well as The traffic is sent to the network entity in a plurality of physical uplink shared channels (PUSCHs) within the data period.
2. The method according to claim 1, wherein: The one or more CG configurations indicate the maximum number of PUSCHs for each CG opportunity.
3. The method according to claim 2, wherein the one or more CG configurations also indicate CG parameters used for each PUSCH in the PUSCH.
4. The method of claim 3, wherein at least some of the CG parameters: PUSCH changes within cross-CG opportunities; or Different CG timing changes across data periods.
5. The method according to claim 2, further comprising: Send an indication that the UE does not intend to use all of the maximum number of PUSCHs within the CG opportunity.
6. The method according to claim 5, further comprising: Send an instruction to at least one of the following: a change in one or more CG parameters for one or more subsequent PUSCHs; or A request for a change to one or more CG parameters for one or more subsequent PUSCHs.
7. The method of claim 6, wherein the request is for a change in one or more CG parameters for one or more subsequent PUSCHs in the same CG opportunity, a subsequent CG opportunity, or a subsequent CG opportunity group.
8. The method of claim 6, wherein the change or request for change is indicated via at least one of: sequence-based signaling, uplink control information (UCI), or medium access control (MAC) control element (CE).
9. The method according to claim 2, further comprising: Sending an indication that the UE intends to use more than the maximum number of PUSCHs within the CG opportunity.
10. The method according to claim 2, wherein sending the service to the network entity in a plurality of PUSCHs within the data period comprises: Sending one or more PUSCHs within the at least one CG opportunity; as well as One or more PUSCHs scheduled via one or more dynamic grants are transmitted.
11. The method according to claim 10, further comprising: At least one scheduling request (SR) is sent, wherein at least one of the dynamic grants is transmitted in response to the SR.
12. The method according to claim 10, further comprising: Sending more data indication triggering pre-configured PUSCH resources; as well as A PUSCH is transmitted on at least some of the preconfigured PUSCH resources.
13. The method according to claim 10, further comprising: An indication indicating an end of one of the bursts is sent in one of the PUSCHs.
14. The method according to claim 10, further comprising: A more data indication is sent in one of the PUSCHs, wherein at least one of the dynamic grants is transmitted in response to the more data indication.
15. The method of claim 14, wherein the more data indicator is sent via at least one of: a demodulation reference signal (DMRS), a medium access control (MAC) control element (CE), or uplink control information (UCI).
16. The method of claim 1, wherein the one or more CG configurations include a plurality of CG configurations, each CG configuration having at least one associated CG opportunity within the data period.
17. The method according to claim 16, wherein sending the service to the network entity in multiple PUSCHs within the data period includes sending the service within multiple CG opportunities, each CG opportunity being associated with one CG configuration among the multiple CG configurations.
18. The method according to claim 16, further comprising: Sending more data indication indicating that the UE intends to use at least one CG opportunity or CG configuration within the data period.
19. The method of claim 16, wherein the more data indicator further indicates a modification to one or more CG parameters.
20. The method according to claim 16, further comprising: Send an indication that the UE does not intend to use at least one CG opportunity or CG configuration during the data period.
21. The method of claim 20, wherein the indication is sent via at least one of: sequence-based signaling, uplink control information (DCI), PUSCH, or a medium access control (MAC) control element (CE).
22. The method according to claim 1, further comprising: A wake-up signal (WUS) is sent to the network entity at the beginning of the data period to indicate that the UE does intend to use at least one CG opportunity within the data period.
23. The method of claim 22, wherein the WUS is transmitted at a fixed offset from a first PUSCH transmitted by the UE.
24. The method of claim 22, wherein the WUS further indicates a modification to one or more CG parameters.
25. The method of claim 22, wherein the WUS is sent via at least one of: sequence-based signaling, uplink control information (DCI), or a medium access control (MAC) control element (CE).
26. A method for wireless communication by a network entity, the method comprising: sending one or more configuration grant (CG) configurations to a user equipment (UE), each configuration grant (CG) configuration defining at least one CG opportunity within a data period; as well as Uplink traffic from the UE is monitored in a plurality of physical uplink shared channels (PUSCHs) within the data period.
27. The method of claim 26, wherein: The one or more CG configurations indicate the maximum number of PUSCHs for each CG opportunity.
28. The method of claim 26, wherein the one or more CG configurations include a plurality of CG configurations, each CG configuration having at least one associated CG opportunity within the data period.
29. A user equipment (UE) configured for wireless communication, the user equipment (UE) comprising: a memory including computer executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the UE to: receiving one or more configuration grant (CG) configurations from a network entity, each configuration grant (CG) configuration defining at least one CG opportunity within a data period; as well as Obtaining one or more bursts of services; as well as The traffic is sent to the network entity in a plurality of physical uplink shared channels (PUSCHs) within the data period.
30. A network entity configured for wireless communication, the network entity comprising: a memory including computer executable instructions; and one or more processors configured to execute the computer executable instructions and cause the network entity to: sending one or more configuration grant (CG) configurations to a user equipment (UE), each configuration grant (CG) configuration defining at least one CG opportunity within a data period; as well as Uplink traffic from the UE is monitored in a plurality of physical uplink shared channels (PUSCHs) within the data period.
