System and method for multi-PxSCH signaling at high frequency

Abstract

The present disclosure relates to techniques for performing wireless communications, including signaling resource allocation for multiple transport blocks (TBs) on a PUSCH or PDSCH using a single control element, such as a DCI. In various scenarios, the multiple TBs can be scheduled on contiguous or non-contiguous time domain resources. Various mechanisms are disclosed for performing this signaling resource allocation for the multiple TBs without introducing excessive signaling overhead.

Description

Technical Field

[0001] The present application relates to wireless communications, including improved signaling for multi-way communications.

[0002] Related technical description

[0003] The use of wireless communication systems is growing rapidly. In addition, wireless communication technology has evolved from only voice communication to also include the transmission of data such as the Internet and multimedia content.

[0004] Mobile electronic devices may take the form of smartphones or tablets that are commonly carried by users. Wearable devices (also known as accessory devices) are a newer form of mobile electronic device, an example of which is the smartwatch. In addition, low-cost, low-complexity wireless devices intended for static or dynamic deployment are also rapidly increasing as part of the development of the "Internet of Things". In other words, the complexity, capabilities, traffic patterns and other characteristics of the required devices are becoming increasingly broad. In general, it is desirable to recognize and provide improved support for a wide range of required wireless communication characteristics. One characteristic may be to increase the efficiency of signaling multiplexing. Improvements in this area are desired. Summary of the Invention

[0005] Embodiments are presented herein, particularly systems, apparatus, and methods for sending multiple PUSCH or PDSCH transmissions using a single control element, such as DCI.

[0006] As described above, there are an increasing number of use cases for wireless network communications with different types of user equipment devices (UEs) with widely varying capabilities and usage expectations. One direction of expansion of possible use cases supported by wireless communication technologies can include increasing the use of techniques for scheduling multi-way communications, such as multiple transport blocks on a physical uplink shared channel (PUSCH) and / or a physical downlink shared channel (PDSCH) (e.g., multiple PxSCHs). A base station scheduling multiple PxSCH transmissions can employ various procedures to signal resource allocations for multiple TBs to a UE while avoiding excessive signaling overhead. Such procedures, as well as various systems and apparatus for implementing such procedures, are described herein.

[0007] For example, a method for delivering payload data messages in a wireless communication network is disclosed. A base station of the wireless communication network may transmit a control message indicating downlink transmission resources allocated for multiple payload data messages. The base station may then transmit the multiple payload data messages based on the allocated downlink transmission resources.

[0008] In some scenarios, multiple payload data messages may be sent on a physical downlink shared channel (PDSCH).In some scenarios, the control message may be a downlink control indicator (DCI).

[0009] In some scenarios, the allocated downlink transmission resources may include transmission resources that are discontinuous in time.

[0010] In some scenarios, the base station may generate the control message, where the generation may include configuring the control message to include an allocation of the downlink transmission resources for the multiple payload data messages in response to determining that at least one of the multiple payload data messages will be sent within a specific frequency range.

[0011] In some scenarios, the control message may include an indication of corresponding time domain resources allocated to each of the payload data messages, wherein the indication of corresponding time domain resources identifies the corresponding start time and duration of each of the payload data messages.

[0012] In some scenarios, the indication may include an index to a resource allocation table, where the index indicates a single entry of the table, the single entry identifying the respective time-domain resources allocated to each of the payload data messages.

[0013] In some scenarios, the indication may include, for each of the payload data messages, a corresponding index to a resource allocation table, wherein each index indicates a different entry of the table, wherein each indicated entry of the table identifies a corresponding time domain resource allocated to the associated payload data message.

[0014] In some scenarios, the indication may include an index to a resource allocation table, wherein the index indicates a first entry of the table, the first entry identifying a corresponding time-domain resource allocated to at least a first payload data message in the payload data messages. The indication may also include at least one offset value, the at least one offset value identifying a second entry of the table by identifying a position of the second entry relative to the first entry, the second entry identifying a corresponding time-domain resource allocated to at least a second payload data message in the payload data messages;

[0015] In some scenarios, each indicated entry of the table may include at least one value that indicates the time slot in which transmission of the corresponding payload data message is scheduled to start by specifying a delay between the time slot in which the control message is sent and the time slot in which transmission of the corresponding payload data message is scheduled to start.

[0016] In some scenarios, the first entry of the table may include at least one value indicating the time slot in which transmission of the corresponding first payload data message is scheduled to start by specifying a delay between the time slot in which the control message is sent and the time slot in which transmission of the corresponding first payload data message is scheduled to start. The second entry of the table may include at least one value indicating the time slot in which transmission of the corresponding second payload data message is scheduled to start by specifying a delay between the time slot in which the most recent payload data message of the corresponding first payload data message is scheduled to start and the time slot in which each corresponding second payload data message is scheduled to start.

[0017] In some scenarios, the indication may include a first index to a first time-domain resource allocation table, wherein the first index indicates an entry of the first table, wherein the entry of the first table includes at least one value that indicates the time slot in which transmission of the corresponding first payload data message is scheduled to start by specifying a delay between the time slot in which the control message is sent and the time slot in which transmission of the corresponding first payload data message is scheduled to start. The indication may also include a second index to a second time-domain resource allocation table, the second index occupying fewer bits of the control message than the first index, wherein the second index indicates an entry of the second table, wherein the entry of the second table includes at least one value that indicates the time slot in which transmission of the corresponding second payload data message is scheduled to start by specifying a delay between the time slot in which the most recent payload data message of the corresponding first payload data message is scheduled to start and the time slot in which each corresponding second payload data message is scheduled to start.

[0018] In some scenarios, for each of the payload data messages, the control message may further indicate a resource allocation for sending an acknowledgement (ACK) feedback message in response to the corresponding payload data message.

[0019] In some scenarios, the control message may include an indication of a frequency hopping configuration for each transmission time interval (TTI).

[0020] In some scenarios, the base station may send a second control message indicating uplink transmission resources allocated for a second plurality of payload data messages, and receive the second plurality of payload data messages according to the allocated uplink transmission resources. In some such scenarios, the second plurality of payload data messages may be received on a physical uplink shared channel (PUSCH).

[0021] In another example, a method for delivering payload data messages in a wireless communication network is disclosed. A base station of the wireless communication network may transmit a control message indicating uplink transmission resources allocated for multiple payload data messages, where the uplink transmission resources are discontinuous in the time domain. The base station may also receive the multiple payload data messages based on the allocated uplink transmission resources.

[0022] In some scenarios, the control message may include an indication of corresponding time domain resources allocated to each of the payload data messages, wherein the indication of corresponding time domain resources identifies the corresponding start time and duration of each of the payload data messages.

[0023] Disclosed are apparatus and systems for implementing any of the foregoing methods, as well as other methods disclosed herein.

[0024] The techniques described herein may be implemented in and / or used with a number of different types of devices, including but not limited to mobile phones or smartphones (e.g., iPhones TM , based on Android TM phones), tablets (e.g., iPad TM 、Samsung Galaxy TM ), portable gaming devices (e.g., Nintendo DS TM PlayStation Portable TM 、Gameboy Advance TM , iPhone TM ), wearable devices (e.g., smart watches, smart glasses), laptops, PDAs, portable internet devices, music players, data storage devices, other handheld devices, vehicles, cars, unmanned aerial vehicles (e.g., drones) and unmanned flight controllers, other cellular network infrastructure equipment, servers, and any of various other computing devices.

[0025] This summary is intended to provide a brief overview of some of the subject matter described in this document. It should be understood, therefore, that the foregoing features are merely illustrative and should not be construed as narrowing the scope or spirit of the subject matter described herein in any way. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following detailed description, accompanying drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] A better understanding of the present subject matter may be obtained when the following detailed description of the embodiments is considered in conjunction with the accompanying drawings.

[0027] Figure 1 An example wireless communication system including an accessory device according to some embodiments is shown;

[0028] Figure 2 An example wireless communication system is shown in which two wireless devices can perform direct device-to-device communication according to some embodiments;

[0029] Figure 3 is a block diagram illustrating an example wireless device according to some embodiments;

[0030] Figure 4 is a block diagram illustrating an example base station according to some embodiments;

[0031] Figures 5 to 7 illustrates aspects of multiple PUSCH scheduling according to some embodiments;

[0032] Figures 8 to 10 shows a portion of an example TDRA table for signaling resource allocation for multiple PxSCH transmissions according to some embodiments;

[0033] Figure 11 shows an example of a differential index offset table according to some embodiments;

[0034] Figures 12 to 13 is a time domain resource diagram illustrating example resource allocation for multiple PxSCH transmissions according to some embodiments;

[0035] Figures 14 to 16 is a time / frequency domain diagram illustrating an example frequency hopping configuration for use with multiple PxSCH transmissions according to some embodiments; and

[0036] Figure 17 is a flow chart illustrating an example method for delivering payload data messages according to some embodiments.

[0037] While the features described herein are susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. However, it should be understood that the drawings and detailed description thereof are not intended to limit this disclosure to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the subject matter as defined by the appended claims. DETAILED DESCRIPTION

[0038] Acronyms and abbreviations

[0039] The following acronyms and abbreviations are used in this disclosure:

[0040] 3GPP: Third Generation Partnership Project

[0041] CBGFI: Codebook Group Refresh Index

[0042] CBGTI: Codebook Group Transmission Index

[0043] CE: Control Element

[0044] DAI: Downlink Allocation Index

[0045] DCI: Downlink Control Indicator

[0046] DL: Downlink

[0047] FDRA: Frequency Domain Resource Allocation

[0048] GSM: Global System for Mobile Communications

[0049] HARQ: Hybrid Automatic Repeat Request

[0050] LTE: Long Term Evolution

[0051] MAC: Media Access Control

[0052] MCS: Modulation and Coding Scheme

[0053] NDI: New Data Indicator

[0054] PDSCH: Physical Downlink Shared Channel

[0055] PRI: PUCCH resource indicator

[0056] PUCCH: Physical Uplink Control Channel

[0057] PUSCH: Physical Uplink Shared Channel

[0058] PxSCH: Reference PDSCH or PUSCH

[0059] RRC: Radio Resource Control

[0060] RV: Redundant Version

[0061] SCS: Subcarrier Spacing

[0062] TDRA: Time Domain Resource Allocation

[0063] TTI: Transmission Time Interval

[0064] UL: Uplink

[0065] UMTS: Universal Mobile Telecommunications System

[0066] the term

[0067] The following are definitions of terms used in this disclosure:

[0068] Memory medium - any of various types of non-transitory memory devices or storage devices. The term "memory medium" is intended to include installation media, for example, CD-ROMs, floppy disks, or tape devices; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, for example, hard drives or optical storage devices; registers or other similar types of memory elements, etc. The memory medium may also include other types of non-transitory memory or a combination thereof. In addition, the memory medium may be located in the first computer system that executes the program, or may be located in a different second computer system that is connected to the first computer system via a network such as the Internet. In the latter case, the second computer system may provide program instructions to the first computer for execution. The term "memory medium" may include two or more memory media that may reside in different locations in different computer systems connected, for example, via a network. The memory medium may store program instructions (for example, expressed as a computer program) that can be executed by one or more processors.

[0069] Carrier Medium—storage media as described above, and physical transmission media such as a bus, network, and / or other physical transmission media that transport signals such as electrical, electromagnetic, or digital signals.

[0070] Programmable hardware elements—include various hardware devices that include multiple programmable function blocks connected via programmable interconnects. Examples include FPGAs (field programmable gate arrays), PLDs (programmable logic devices), FPOAs (field programmable object arrays), and CPLDs (complex PLDs). Programmable function blocks can range from fine-grained (combinational logic units or lookup tables) to coarse-grained (arithmetic logic units or processor cores). Programmable hardware elements may also be referred to as "configurable logic units."

[0071] Computer System—Any of various types of computing or processing systems, including a personal computer system (PC), a mainframe computer system, a workstation, a network appliance, an Internet appliance, a personal digital assistant (PDA), a television system, a grid computing system, or other devices or combinations of devices. In general, the term "computer system" can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0072] User Equipment (UE) (or "UE device") - any of various types of computer systems or devices that are mobile or portable and that perform wireless communication. Examples of UE devices include mobile phones or smartphones (e.g., iPhones). TM, based on Android TM phones), tablets (e.g., iPad TM 、Samsung Galaxy TM ), portable gaming devices (e.g., Nintendo DS TM PlayStation Portable TM 、Gameboy Advance TM , iPhone TM ), wearable devices (e.g., smart watches, smart glasses), laptops, PDAs, portable internet devices, music players, data storage devices, other handheld devices, vehicles, cars, unmanned aerial vehicles (e.g., drones) and unmanned flight controllers, etc. In general, the term "UE" or "UE device" can be broadly defined to cover any electronic device, computing device and / or telecommunication device (or combination of these devices) that is easily transportable by a user and capable of wireless communication.

[0073] Wireless Device—Any of various types of computer systems or devices that perform wireless communications. A wireless device may be portable (or mobile), or may be stationary or fixed in place. A UE is an example of a wireless device.

[0074] Communication Device—Any of various types of computer systems or devices that perform communication, either wired or wireless. A communication device may be portable (or mobile), or stationary or fixed in place. A wireless device is one example of a communication device. A UE is another example of a communication device.

[0075] Base Station—The term “base station” has the full breadth of its ordinary meaning and includes at least a wireless communication station that is installed at a fixed location and used to communicate as part of a wireless communication system.

[0076] Link budget limited—includes the full scope of its ordinary meaning and includes at least a characteristic of a wireless device (e.g., UE) that exhibits limited communication capabilities or limited power relative to devices that are not link budget limited or relative to devices for which a radio access technology (RAT) standard has been developed. A link budget limited wireless device may experience relatively limited receive capability and / or transmit capability, which may be due to one or more factors, such as device design, device size, battery size, antenna size or design, transmit power, receive power, current transmission medium conditions, and / or other factors. Such devices may be referred to herein as “link budget limited” (or “link budget constrained”) devices. A device may be inherently link budget limited due to the size of the device, battery power, and / or transmit / receive power. For example, a smartwatch communicating with a base station via LTE or LTE-A may be inherently link budget limited due to its reduced transmit / receive power and / or antenna reduction. Wearable devices such as smartwatches are generally link budget limited devices. Alternatively, a device may not be inherently link budget limited, e.g., may have sufficient size, battery power, and / or transmit / receive power for normal communication over LTE or LTE-A, but may be temporarily link budget limited due to current communication conditions, e.g., a smartphone at a cell edge, etc. It is noted that the term "link budget limited" includes or encompasses power limitations, and thus a link-limited device may be considered a link budget limited device.

[0077] Processing element (or processor)—refers to any element or combination of elements capable of performing functions in a device (e.g., a user equipment device or a cellular network device). A processing element may include, for example, a processor and associated memory, portions or circuits of individual processor cores, an entire processor core, a separate processor, an array of processors, circuits such as ASICs (application-specific integrated circuits), programmable hardware elements such as field-programmable gate arrays (FPGAs), and any of the above combinations.

[0078] Automatic—refers to an action or operation performed by a computer system (e.g., software executed by the computer system) or a device (e.g., a circuit, a programmable hardware element, an ASIC, etc.) without requiring user input to directly specify or execute the action or operation. Thus, the term "automatically" is in contrast to an action being manually performed or specified by a user, where the user provides input to directly perform the action. An automatic process may be initiated by input provided by a user, but the subsequent actions performed "automatically" are not specified by the user, i.e., they are not performed "manually," where the user specifies each action to be performed. For example, a user filling out an electronic form by selecting each field and providing input specifying information (e.g., by typing information, selecting checkboxes, radio selections, etc.) is not manually filling out the form, even though the computer system must update the form in response to the user's actions. The form can be automatically filled out by a computer system, where the computer system (e.g., software executing on the computer system) analyzes the fields of the form and fills it out without requiring any user input to specify the answers to the fields. As indicated above, a user can invoke the automatic filling of a form without participating in the actual filling out of the form (e.g., the user does not manually specify the answers to the fields; they are automatically completed). This specification provides various examples of operations that are automatically performed in response to actions that a user has taken.

[0079] Configured to - Various components may be described as being "configured to" perform one or more tasks. In such contexts, "configured to" is a broad statement that generally means "having the structure" to perform one or more tasks during operation. Thus, a component can be configured to perform a task even when the component is not currently performing the task (e.g., a set of electrical conductors can be configured to electrically connect a module to another module even when the two modules are not connected). In some contexts, "configured to" can be a broad statement that generally means "having the circuitry" to carry out one or more tasks during operation. Thus, a component can be configured to perform a task even when the component is not currently turned on. Generally, the circuitry that forms the structure corresponding to "configured to" may include hardware circuitry.

[0080] For ease of description, various components may be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to." Representing a component as being configured to perform one or more tasks expressly does not invoke the sixth paragraph of section 112 of title 35 of the United States Code for that component.

[0081] Figure 1-Figure 2 —Wireless communication system

[0082] Figure 1 An example of a wireless cellular communication system is illustrated. It should be noted that Figure 1This represents one possibility among many, and the features of the present disclosure may be implemented by any of a variety of systems as desired. For example, the embodiments described herein may be implemented in any type of wireless device.

[0083] As shown, the exemplary wireless communication system includes a cellular base station 102 that communicates over a transmission medium with one or more wireless devices 106A, 106B, etc., and an accessory device 107. Wireless devices 106A, 106B, and 107 may be user equipment, which may be referred to herein as "user equipment" (UE) or UE devices.

[0084] Base station 102 may be a base transceiver station (BTS) or a cell site and may include hardware and / or software that enables wireless communication with UE devices 106A, 106B, and 107. If base station 102 is implemented in the context of LTE, it may be referred to as an "eNodeB" or "eNB." If base station 102 is implemented in the context of 5G NR, it may alternatively be referred to as a "gNodeB" or "gNB." Base station 102 may also be equipped to communicate with network 100 (e.g., a core network of a cellular service provider, a telecommunications network such as a public switched telephone network (PSTN), and / or the Internet, among various possible networks). Thus, base station 102 may facilitate communication between UE device 106 and UE device 107 and / or between UE device 106 / 107 and network 100. Also as used herein, with respect to a UE, a base station may sometimes be considered to represent the network in considering the UE's uplink (UL) and downlink (DL) communications. Therefore, a UE communicating with one or more base stations in a network may also be understood as a UE communicating with the network.

[0085] In other embodiments, the base station 102 may be configured to provide communications via one or more other wireless technologies, such as an access point supporting one or more WLAN protocols, such as 802.11a, b, g, n, ac, ad, and / or ax, or LTE in the unlicensed band (LAA).

[0086] The communication area (or coverage area) of the base station 102 may be referred to as a “cell.” The base station 102 and the UEs 106 / 107 may be configured to communicate over a transmission medium using any of a variety of radio access technologies (RATs) or wireless communication technologies, such as GSM, UMTS (WCDMA, TDS-CDMA), LTE, LTE-Advanced (LTE-A), NR, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), Wi-Fi, etc.

[0087] Thus, base station 102 and other similar base stations (not shown) operating according to one or more cellular communication technologies can be provided as a cell network that can provide continuous or nearly continuous overlapping service to UE devices 106A-N and UE device 107 and similar devices within a geographic area via one or more cellular communication technologies.

[0088] Note that, at least in some cases, UE devices 106 / 107 may be capable of communicating using any of a variety of wireless communication technologies. For example, UE devices 106 / 107 may be configured to communicate using one or more of GSM, UMTS, CDMA2000, LTE, LTE-A, NR, WLAN, Bluetooth, one or more global navigation satellite systems (GNSS, such as GPS or GLONASS), one and / or more mobile television broadcast standards (e.g., ATSC-M / H), etc. Other combinations of wireless communication technologies (including more than two wireless communication technologies) are also possible. Similarly, in some cases, UE devices 106 / UE devices 107 may be configured to communicate using only a single wireless communication technology.

[0089] UE 106A and UE 106B may comprise handheld devices such as smartphones or tablets, and / or may comprise any of various types of devices with cellular communication capabilities. For example, one or more of UE 106A and UE 106B may be wireless devices intended for static or dynamic deployment, such as appliances, measurement devices, control devices, and the like. UE 106B may be configured to communicate with a UE device 107, which may be referred to as an accessory device 107. Accessory device 107 may be any of various types of wireless devices, typically wearable devices with a smaller form factor and limited battery, output power, and / or communication capabilities relative to UE 106. As a common example, UE 106B may be a smartphone carried by a user, and accessory device 107 may be a smartwatch worn by the same user. UE 106B and accessory device 107 may communicate using any of various short-range communication protocols, such as Bluetooth or Wi-Fi. In some cases, UE 106B and accessory device 107 can utilize proximity services (ProSe) technology, for example, in a manner supported by a cellular base station, to perform direct peer-to-peer communications. For example, such ProSe communications can be performed as part of a relay link to support a radio resource control connection between accessory device 107 and BS 102, such as according to various embodiments described herein.

[0090] UE 106B may also be configured to communicate with UE 106A. For example, UE 106A and UE 106B may be able to perform direct device-to-device (D2D) communications. D2D communications may be supported by cellular base station 102 (e.g., BS 102 may facilitate discovery, as well as various possible forms of assistance), or may be performed in a manner not supported by BS 102. For example, it may be possible for UE 106A and UE 106B to arrange and perform D2D communications (e.g., including discovery communications) even when BS 102 and other cellular base stations have no coverage.

[0091] BS 102 may control one or more transmit and receive points (TRPs) and may use the TRPs to communicate with UEs. The TRPs may be collocated with the BS and / or at a separate physical location.

[0092] Figure 2 An exemplary BS 102 is shown communicating with a UE device 106, which in turn communicates with an accessory device 107. The UE device 106 and the accessory device 107 may be any of a mobile phone, a tablet or any other type of handheld device, a smartwatch or other wearable device, a media player, a computer, a laptop, an unmanned aerial vehicle (UAV), an unmanned flight controller, a vehicle, or virtually any type of wireless device. In some embodiments, the accessory device may be a wireless device designed to have low cost and / or low power consumption, and may benefit from a relay link with the UE device 106 (and / or another companion device) to support communications with the BS 102. For example, in Figure 2 In the exemplary scenario of FIG, a device that utilizes a relay link with another wireless device to communicate with a cellular base station may also be referred to herein as a remote wireless device, a remote device, or a remote UE apparatus, and a wireless device that provides such a relay link may also be referred to herein as a relay wireless device, a relay device, or a relay UE device. According to some embodiments, such BS 102, UE 106, and accessory device 107 may be configured to perform radio resource control procedures for the remote wireless device according to the various techniques described herein.

[0093] UE 106 and accessory device 107 may each include a device or integrated circuit known as a cellular modem for facilitating cellular communications. The cellular modem may include one or more processors (processing elements) configured to execute program instructions stored in a memory and / or various hardware components described herein. UE 106 and / or accessory device 107 may each perform any of the method implementations described herein by executing such stored instructions. Alternatively or in addition, UE 106 and / or accessory device 107 may include a programmable hardware element, such as an FPGA (field programmable gate array), an integrated circuit, and / or any of various other possible hardware components, configured to (e.g., individually or in combination) perform any of the method implementations described herein or any portion of any of the method implementations described herein. The cellular modem described herein may be used in a UE device as defined herein, a wireless device as defined herein, or a communication device as defined herein. The cellular modem described herein may also be used in a base station or other similar network-side device.

[0094] The UE 106 and / or the accessory device 107 may include one or more antennas for communicating in accordance with one or more RAT standards using one or more wireless communication protocols. In some embodiments, one or both of the UE 106 or the accessory device 107 may be configured to communicate using a single shared radio. The shared radio may be coupled to a single antenna, or may be coupled to multiple antennas (e.g., for MIMO) for performing wireless communications. Generally, the radio may include any combination of a baseband processor, analog radio frequency (RF) signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc.), or digital processing circuitry (e.g., for digital modulation and other digital processing). Similarly, the radio may implement one or more receive chains and transmit chains using the aforementioned hardware.

[0095] Alternatively, UE 106 and / or accessory device 107 may include two or more radios. For example, in some embodiments, UE 106 and / or accessory device 107 may include a separate transmit chain and / or receive chain (e.g., including separate antennas and other radios) for each wireless communication protocol with which it is configured to communicate. As another possibility, UE 106 and / or accessory device 107 may include one or more radios shared between multiple wireless communication protocols, and one or more radios used uniquely by a single wireless communication protocol. For example, UE 106A and / or accessory device 107 may include a shared radio for communicating using either LTE or CDMA2000 1xRTT (or LTE or NR, or LTE or GSM), and a shared radio for communicating using Wi-Fi and BLUETOOTH. TM Each of the two devices communicates with a separate radio component. Other configurations are also possible.

[0096] Figure 3 —Block diagram of UE equipment

[0097] Figure 3 A possible block diagram of a UE device, such as UE device 106 or 107, is shown. As shown, UE device 106 / 107 may include a system on a chip (SOC) 300, which may include components for various purposes. For example, as shown, SOC 300 may include a processor 302, which may execute program instructions for UE device 106 / 107, and display circuitry 304, which may perform graphics processing and provide display signals to display 360. SOC 300 may also include motion sensing circuitry 370, which may detect motion of UE 106, for example, using a gyroscope, an accelerometer, and / or any of various other motion sensing components. Processor 302 may also be coupled to a memory management unit (MMU) 340, which may be configured to receive addresses from processor 302 and translate those addresses into locations in memory (e.g., memory 306, read-only memory (ROM) 350, flash memory 310) and / or other circuits or devices, such as display circuit 304, radio 330, I / F 320, and / or display 360. MMU 340 may be configured to perform memory protection and page table translation or setup. In some embodiments, MMU 340 may be included as part of processor 302.

[0098] As shown, the SOC 300 may be coupled to various other circuits of the UE 106 / 107. For example, the UE 106 / 107 may include various types of memory (e.g., including NAND flash memory 310), a connector interface 320 (e.g., for coupling to a computer system, a docking station, a charging station, etc.), a display 360, and wireless communication circuitry 330 (e.g., for LTE, LTE-A, NR, CDMA2000, Bluetooth, Wi-Fi, NFC, GPS, etc.).

[0099] The UE device 106 / 107 may include at least one antenna and, in some embodiments, may include multiple antennas 335a and 335b for performing wireless communications with a base station and / or other devices. For example, the UE device 106 / 107 may use antennas 335a and 335b to perform wireless communications. As described above, the UE device 106 / 107 may, in some embodiments, be configured to perform wireless communications using multiple wireless communication standards or radio access technologies (RATs).

[0100] Wireless communication circuitry 330 may include Wi-Fi logic 332, a cellular modem 334, and Bluetooth logic 336. Wi-Fi logic 332 is configured to enable UE device 106 / 107 to perform Wi-Fi communications over an 802.11 network. Bluetooth logic 336 is configured to enable UE device 106 / 107 to perform Bluetooth communications. Cellular modem 334 may be a relatively low-power cellular modem capable of performing cellular communications according to one or more cellular communication technologies.

[0101] As described herein, UE 106 / 107 may include hardware components and software components for implementing embodiments of the present disclosure. The processor 302 of the UE device 106 / UE device 107 may be configured to implement part or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). In other embodiments, the processor 302 may be configured as a programmable hardware element, such as an FPGA (field programmable gate array) or as an ASIC (application-specific integrated circuit). In addition, the processor 302 may be coupled to a processor such as a processor 106 / 107. Figure 3The other components shown and / or may interoperate with the other components to perform radio resource control processes for remote wireless devices in accordance with various embodiments disclosed herein. The processor 302 may also implement various other applications and / or end-user applications running on the UE 106. Alternatively or in addition, one or more components of the wireless communication circuitry 330 (e.g., the cellular modem 334) of the UE device 106 / 107 may be configured to implement some or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium), a processor configured as an FPGA (field programmable gate array), and / or using dedicated hardware components that may include an ASIC (application-specific integrated circuit).

[0102] Figure 4 —Block diagram of a base station

[0103] Figure 4 1 shows an exemplary block diagram of a base station 102 according to some embodiments. Note that Figure 4 The base station 102 is only one example of a possible base station. As shown, the base station 102 may include a processor 404 that may execute program instructions for the base station 102. The processor 404 may also be coupled to a memory management unit (MMU) 440 or other circuit or device that may be configured to receive addresses from the processor 404 and translate those addresses into locations in memory (e.g., memory 460 and read-only memory (ROM) 450).

[0104] The base station 102 may include at least one network port 470. Figure 1 and Figure 2 As described in , the network port 470 can be configured to couple to a telephone network and provide multiple devices, such as the UE devices 106 / 107 , with access to the telephone network.

[0105] The network port 470 (or an additional network port) may also or alternatively be configured to couple to a cellular network, such as a core network of a cellular service provider. The core network may provide mobility-related services and / or other services to a plurality of devices, such as the UE devices 106 / 107. For example, the core network may include, for example, a mobility management entity (MME) for providing mobility management services, a serving gateway (SGW) and / or a packet data network gateway (PGW) for providing external data connections, such as to the Internet, and the like. In some cases, the network port 470 may be coupled to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., between other UE devices served by the cellular service provider).

[0106] Base station 102 may include at least one antenna 434 and possibly multiple antennas. One or more antennas 434 may be configured to operate as a wireless transceiver and may be further configured to communicate with UE devices 106 / 107 via radio 430. Antenna 434 communicates with radio 430 via communication chain 432. Communication chain 432 may be a receive chain, a transmit chain, or both. Radio 430 may be configured to communicate via various wireless communication standards, including but not limited to LTE, LTE-A, NR, GSM, UMTS, CDMA2000, Wi-Fi, and the like.

[0107] Base station 102 may be configured to communicate wirelessly using multiple wireless communication standards. In some cases, base station 102 may include multiple radios that may enable base station 102 to communicate according to multiple wireless communication technologies. For example, as one possibility, base station 102 may include an LTE radio for communicating according to LTE and a Wi-Fi radio for communicating according to Wi-Fi. In such a case, base station 102 may be capable of operating as both an LTE base station and a Wi-Fi access point. As another possibility, base station 102 may include a multimode radio capable of communicating according to any of multiple wireless communication technologies (e.g., LTE and NR, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, etc.).

[0108] As further described later herein, the base station 102 may include hardware and software components for implementing or supporting implementations of the features described herein. According to some embodiments, the processor 404 of the base station 102 may be configured to implement part or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively, the processor 404 may be configured as a programmable hardware element such as an FPGA (field programmable gate array), or as an ASIC (application-specific integrated circuit), or a combination thereof. Alternatively (or in addition), in combination with one or more of the other components 430, 432, 434, 440, 450, 460, 470, the processor 404 of the BS 102 may be configured to implement or support implementation of any of the various other features of the radio resource control process for remote wireless devices according to the various embodiments described herein, and / or the features described herein.

[0109] Figures 5 to 7 -Scheduling multiple communications

[0110] Scheduling multiple communications using a single scheduling message can allow, for example, to reduce overhead relative to individual scheduling of communications. Thus, wireless communications such as New Radio (NR) and NR-Unlicensed (NR-U) can support arrangements where multiple uplink (UL) and / or downlink (DL) communications (e.g., to occur over a period of time) are scheduled using a single scheduling message. For example, a base station can schedule multiple physical UL shared channel (PUSCH) and / or physical DL shared channel (PDSCH) messages together (e.g., multiple PxSCH messages can refer to multiple UL and / or DL ​​communications on the respective shared channels).

[0111] Figure 5 An example of multi-PUSCH scheduling according to some embodiments is shown. As shown in the figure, in a first example, a PUSCH transmission transport block (TB) 510 can be scheduled to be repeated at multiple transmission time intervals (e.g., multi-TTI PUSCH transmission or multi-PUSCH transmission). This repetition in time can support reliability (e.g., for ultra-reliable low latency communication (URLLC) services) or otherwise ensure UL coverage. As used herein, references to "PDSCH" or "PDSCH message" can refer to a TB sent on the PDSCH. Similarly, references to "PUSCH" or "PUSCH message" can refer to a TB sent on the PUSCH.

[0112] In a second example, a multi-TTI PUSCH transmission can be used to schedule multiple time slots and / or mini-time slots (e.g., 520, 530, 540, and 550) with different TBs using a single UL grant. The TBs can be scheduled at non-periodic times. This can allow for greater efficiency. For example, when using unlicensed spectrum, scheduling the TBs sequentially can allow for increased UL transmission probability, for example, because other users may not contend for the spectrum between transmissions. Currently, the 3GPP standard only provides for transmission of multiple TBs on PUSCH within such sequential (i.e., continuous) transmissions, such as in the unlicensed frequency range, based on a single UL grant signaled by a single DCI.

[0113] Figure 6 Various fields from an example DCI that can be used to schedule such consecutive multiple PUSCH transmissions are shown. In some scenarios, the fields shown can be included in an information element or other message for time domain resource allocation (TDRA), such as: pusch-TimeDomainAllocationListForMultiPUSCH and / or PUSCHTimeDomainResourceAllocationList-r16, as well as various other possibilities. Such fields can be used to configure the TDRA table for multi-PUSCH scheduling.

[0114] Figure 7 An example portion of a TDRA table that can be used to schedule such consecutive multiple PUSCH transmissions according to some embodiments is shown. As shown, multiple TDRA index values ​​can be configured with various parameters. The parameters can include K2 (e.g., the delay between the time slot in which the DCI and the applicable PDSCH will be sent, such as measured in time slots), S (e.g., the symbol at which a particular communication starts), L (e.g., the length of each communication, such as in symbols), and a mapping type. S and L can be referred to as start and length indicator values ​​(SLIVs). Additional fields or different fields can be included as needed. Further, the time units can be different, etc.

[0115] In some embodiments, multi-TTI PUSCH scheduling may use DCI format 0_1. The TDRA table configuration may allow single or multiple consecutive PxSCHs to be indicated in any of multiple scheduled slots.

[0116] In some embodiments, a maximum number of PxSCHs in a row may be set. For example, such a maximum value may be 8, among other possibilities.

[0117] In some embodiments, the number of new data indicator (NDI) bits and / or redundancy version (RV) bits for DCI format 0_1 ​​may be determined based on the configured TDRA table. For example, when multiple PxSCHs are scheduled, one RV bit per PxSCH may be used. The RV may be a value of {0, 2}. When only a single PxSCH is scheduled, two RV bits may be used for the PxSCH.

[0118] In some embodiments, the TDRA table can be extended so that each row indicates multiple PxSCHs (e.g., consecutive in the time domain). Each PxSCH can have a separate SLIV and mapping type. The number of scheduled PxSCHs can be signaled by the number of valid SLIVs indicated in the row of the TDRA table signaled in the DCI.

[0119] Dynamic PxSCH scheduling parameters

[0120] In some scenarios, further improvements are expected to allow multi-path communications to be scheduled more efficiently using a single control element (such as a single DCI). For example, at high frequencies (e.g., above 52.6 GHz), phase noise increases, which can encourage system designers to compensate by increasing the size of the subcarrier spacing (SCS). For example, new SCS candidates such as 480 kHz and / or 960 kHz can be introduced. This in turn reduces the symbol duration, resulting in a greater number of shorter symbols relative to delivering the same amount of data at a lower frequency. This may result in higher scheduling overhead because a greater number of signals need to be scheduled. It may be noted that scheduling each PUSCH and PDSCH via a separate DCI would waste resources, at least because many of the parameters signaled would be redundant on the corresponding DCI. Therefore, it may be advantageous to schedule multiple PUSCHs and / or multiple PDSCHs (i.e., multiple PxSCHs) via a single DCI, for example, to reduce scheduling overhead.

[0121] Additionally, it may be advantageous to allow scheduling of multiple PxSCHs to be signaled in a continuous or non-continuous manner. For example, spacing out scheduled transmissions may allow pre-scheduling of expected DL data that has not yet arrived at the DL buffer (e.g., across multiple time slots). As another example, a transmitter may be scheduled to transmit multiple beams to a single receiver within a scheduling unit, for example, where the scheduling unit may include multiple time slots, rather than a single time slot, to compensate for the reduction in symbol duration by increasing the SCS. Non-continuous scheduling of PxSCHs may allow gaps between transmissions to accommodate downtime experienced during beam switching. As another example, a transmitter may be scheduled to transmit to multiple receivers with various timing requirements (making it necessary to stagger the scheduling of the receivers to meet the timing requirements). Thus, the transmissions scheduled for a given receiver may be non-continuous.

[0122] To schedule multiple PxSCH transmissions between a base station, such as base station 102, and a UE, such as UE 106, both entities should know the parameters of the transmissions. Since the base station typically schedules the transmissions, this may include the base station informing the UE of resource allocations and / or other applicable parameters.

[0123] As a first option, a single DCI may be used to schedule multiple PDSCHs, or a single DCI may be used to schedule multiple PUSCHs.

[0124] As a second option, a single DCI may be used to schedule multiple PDSCHs and / or multiple PUSCHs (ie, multiple PxSCHs).

[0125] As a third option, one or more RRC parameters may be introduced to enable multi-PDSCH and / or multi-PUSCH scheduling, either individually or jointly. For example, one or more RRC parameters may select between the first option and the second option. This may be configured, for example, per UE, per component carrier (CC), per bandwidth part (BWP), per CORESET / SS, etc. As another example, the RRC parameters may select between the first option and the second option by configuring a TDRA table entry. For example, a given TDRA index may indicate scheduling of x PUSCH messages and / or y PDSCH messages.

[0126] Signaling multiple PxSCHs in a single DCI may involve modifying the DCI from its traditional form. For example, the DCI may be modified to include UL and / or DL ​​parameters for each PxSCH, or otherwise indicate parameters that apply to each PxSCH.

[0127] Table 1 shows various UL parameters that may be signaled in a DCI, and various options for signaling those parameters to accommodate multiple PUSCHs.

[0128]

[0129] Table 1

[0130] In Table 1, the first column indicates the parameter to be referenced. The second column indicates the parameters included in the TDRA table, which can be signaled with reference to the TDRA index parameter included in the DCI. Each remaining column indicates an option for signaling those parameters to accommodate multiple PUSCHs. It should be understood that the options shown are examples, and additional examples are also contemplated.

[0131] Option 1 shows a possible parameter configuration suitable for transmitting multiple PUSCHs consecutive in time.

[0132] The frequency domain resource allocation (FDRA) parameter may include an index to an FDRA table, which may include a set of index rows, each of which may indicate a frequency domain resource. The DCI may include an FDRA index to indicate the corresponding frequency domain resource used with the signaled PUSCH. The FDRA may use a bitmap to indicate a specific resource block group (RBG), which includes a set of contiguous virtual resource blocks mapped to a specific (possibly non-contiguous) physical resource block. This is referred to as a Class 0 allocation. The FDRA may also or alternatively use a resource indication value (RIV) indicating the resource block that initiates the allocation and the number of virtual resource blocks allocated to the UE. The virtual resource blocks may then be mapped to a set of physical resource blocks, for example, using non-interleaved mapping. This is referred to as a Class 1 allocation. As shown in Option 1, the FDRA index may be included once for all PUSCHs signaled by the DCI.

[0133] The TDRA parameter may include an index (e.g., 6 bits) to the TDRA table, which may be similar to Figure 7 the parameters shown in. For example, the TDRA table may include a set of index rows, where each row may indicate a time domain resource. The DCI may include a TDRA index to indicate the corresponding time domain resource to be used with the signaled PUSCH message. As shown in Option 1, the TDRA index may be included once for all PUSCH signaled by the DCI. In some scenarios, the TDRA parameter may be or include the pusch-TimeDomainAllocationListForMultiPxSCH field and / or the PUSCHTimeDomainResourceAllocationList-r17 field.

[0134] The row of the TDRA table indicated by the TDRA index may include a set of time domain resource parameters, such as K2 (e.g., the delay between the slot in which the DCI and the applicable PDSCH will be transmitted, e.g., measured in slots), S (e.g., the symbol within the slot where a particular communication starts), L (e.g., the length of each communication path, e.g., in symbols), and the mapping type. The parameters S and L may be referred to together as "SLIV". The values of K2, SLIV, and the mapping type may be configured by RRC message passing. Since in Option 1, the PUSCH is contiguous in time, the RRC message passing may signal a single K2 value (e.g., for the first PUSCH), and the values for each subsequent PUSCH may follow consecutively. For each of SLIV and the mapping type, the RRC message passing may signal N values, where N is the number of PUSCH to be signaled in the DCI (or the maximum number of PUSCH that may be signaled). Thus, each row of the TDRA table may include N values of K2, SLIV, and the mapping type, while the RRC message passing may include only 1 value of K2 and N values of each of SLIV and the mapping type. In some scenarios, the DCI may include an additional value M (where M < N), which indicates the number of entries to be used from each of the values listed for K2, SLIV, and the mapping type. In this way, the TDRA table may be configured to allocate resources for N PUSCH, but the DCI may signal that resources have actually been allocated to only a smaller number (M) of PUSCH.

[0135] The modulation and coding scheme (MCS) parameter may include an index (e.g., 5 bits) to an MCS index table, which may include a set of index rows, where each row may indicate a modulation and coding parameter, such as a modulation order, a target coding rate, and / or a spectral efficiency. The DCI may include an MCS index to indicate the corresponding modulation and coding parameter used with the signaled PUSCH message. As shown in Option 1, the DCI may include a single MCS parameter for all PUSCHs signaled by the DCI.

[0136] A New Data Indicator (NDI) parameter (e.g., 1 bit) may indicate whether a PUSCH includes new data or is a retransmission of previously sent data. As shown in Option 1, the DCI may include an NNDI parameter; e.g., a different NDI parameter for each of the PUSCHs signaled by the DCI.

[0137] A redundancy version (RV) parameter (e.g., 2 bits) may include a specific set of systematic and parity bits used with the HARQ process. As shown in Option 1, the DCI may include N RV parameters; e.g., a different RV parameter for each PUSCH signaled by the DCI.

[0138] A HARQ process number parameter (e.g., 4 bits) may identify the HARQ process for the PUSCH signaled by the DCI. As shown in Option 1, the DCI may signal only a single HARQ process number parameter, e.g., identifying the HARQ process for the first PUSCH signaled by the DCI. The HARQ process number may be incremented for each subsequent PUSCH.

[0139] The downlink allocation index (DAI) identifies the sequence number of the PUSCH within the HARQ bundle. In some scenarios, the two fields DAI1 and DAI2 can be used to define the DAI. For example, when a semi-static codebook is used, DAI1 may include 1 bit to indicate whether the HARQ-ACK codebook is multiplexed with the PUSCH, and DAI2 may be omitted (e.g., may include 0 bits). When a dynamic codebook is used, DAI1 may include 2 bits indicating the total DAI for carriers that do not use a codebook block group (CBG) (e.g., the first subcodebook), and DAI2 may include 2 bits indicating the total DAI for carriers that use a CBG (e.g., the second subcodebook). As shown in Option 1, the DCI may signal N versions of the DAI1 parameter and N versions of the DAI2 parameter; for example, one DAI1 parameter and one DAI2 parameter for each PUSCH in the PUSCH signaled by the DCI.

[0140] Other UL parameters not shown in Table 1 may also be signaled, for example, by DCI. For example, the DCI may include a priority parameter that may indicate whether a PUSCH or multi-PUSCH transmission is of low priority or high priority. As another example, the DCI may include N codebook group transmission index (CBGTI) parameters (e.g., one parameter for each scheduled PUSCH), where each CBGTI includes one bit per CBG that may indicate whether the applicable CBG is to be transmitted.

[0141] Option 2 shows a possible parameter configuration suitable for transmitting multiple PUSCHs that are consecutive in time, where the frequency domain parameters can be configured separately for each PUSCH signaled by the DCI. As shown in Option 2, the parameters are the same as those of Option 1, except that the DCI can signal N values ​​(e.g., N FDRA indices) indicating the FDRA configuration, for example, one parameter is used for each PUSCH in the PUSCH signaled by the DCI. This can allow, for example, the frequency hopping configuration to be selected independently for each PUSCH. In some scenarios, the frequency to be used for the first PUSCH signaled by the DCI can be indicated by a normal FDRA index, but the frequency to be used for subsequent PUSCHs (e.g., in a frequency hopping configuration) can be indicated as a frequency offset, for example, using a frequency domain offset table, as discussed further below. This can reduce the overhead required for the delivery of FDRA parameters for each PUSCH signaled by the DCI.

[0142] In some scenarios, the changes to the FDRA parameters included in the DCI shown for Option 2 may be applied in conjunction with any of Options 3 to 6. For example, Option 2 may be combined with any of Examples 3 to 4 to transmit multiple PUSCHs that are not consecutive in time.

[0143] Option 3 shows a possible parameter configuration suitable for transmitting multiple PUSCHs that are not constrained to be contiguous in time. Specifically, as shown in Option 3, the parameters are the same as those of Option 1, except that the TDRA table can be configured (e.g., via RRC messaging) to include N (e.g., independent) values ​​of K2. This can allow the TDRA table to include K2 values ​​that are spaced apart in time sufficient to result in non-contiguous PUSCHs. This can increase the flexibility of scheduling PUSCHs, but can also increase the complexity of the TDRA table and the size of the RRC message.

[0144] In some scenarios, the changes to the K2 parameter shown for option 3 may be applied in conjunction with option 2 and / or any of options 4 to 6.

[0145] Option 4 shows another possible parameter configuration suitable for sending multiple PUSCHs that are not restricted to being continuous in time. Specifically, as shown in Option 4, the parameters are the same as those of Option 1, except that the DCI can signal N values ​​indicating the TDRA table entries, and the TDRA table entries for K2, SLIV, and mapping can each include a single value. For example, the DCI may include a normal TDRA index (e.g., 6 bits) for each of the N PUSCHs to indicate the row of the TDRA table containing the TDRA parameters to be used for the corresponding PUSCH. However, this will increase the size of the DCI by 6*(N-1). Therefore, more efficient signaling may be required. As an alternative example, the DCI may include a normal TDRA index for only the first PUSCH. For subsequent PUSCHs, the DCI may include an indication of an offset value (e.g., 1 bit, 2 bits, or 3 bits) relative to the first TDRA index, for example, as discussed further below. This can reduce the overhead required for TDRA parameter delivery for each PUSCH signaled by the DCI.

[0146] Because each PUSCH in Option 4 can be configured with its own TDRA parameters, the TDRA table does not need to include multiple K2, SLIV, and Mapping Type parameters on each row. Therefore, each entry for the K2, SLIV, and Mapping Type parameters can contain a single value.

[0147] In some scenarios, the changes to the TDRA parameters shown for option 4 may be applied in conjunction with any of options 2-3 and / or options 5-6.

[0148] Option 5 shows a possible parameter configuration suitable for transmitting multiple PUSCHs that are consecutive in time, where the MCS parameter can be configured separately for each PUSCH signaled by the DCI. As shown in Option 5, the parameters are the same as those of Option 1, except that the DCI can signal N values ​​(e.g., N MCS indices) indicating the MCS configuration, for example, one parameter for each PUSCH in the PUSCH signaled by the DCI. This can allow the MCS configuration to be selected independently for each PUSCH.

[0149] In some scenarios, the change to the MCS parameter included in the DCI shown for Option 5 may be applied in combination with any of Options 2 to 4 and / or Option 6. For example, Option 5 may be combined with any of Examples 3 to 4 to transmit multiple PUSCHs that are not consecutive in time.

[0150] Option 6 illustrates a possible parameter configuration suitable for transmitting multiple PUSCHs that are consecutive in time, where the HARQ process number parameter can be configured separately for each PUSCH signaled by the DCI. As shown in Option 6, the parameters are the same as those of Option 1, except that the DCI can signal N values ​​indicating the HARQ process number, for example, one parameter for each PUSCH signaled by the DCI. This can allow the HARQ process number to be signaled independently for each PUSCH. In some scenarios, it can be assumed that the HARQ process number of each PUSCH will fall within a known range of the HARQ process numbers of the previous PUSCH. In such scenarios, signaling overhead can be reduced by explicitly indicating the HARQ process number of the first PUSCH and then identifying the HARQ process number of each subsequent PUSCH by indicating a differential value (e.g., 2 bits) relative to the HARQ process number of the previous PUSCH.

[0151] In some scenarios, the changes to the MCS parameters included in the DCI shown for Option 6 may be applied in combination with any of Options 2 to 5. For example, Option 6 may be combined with any of Examples 3 to 4 to transmit multiple PUSCHs that are not consecutive in time.

[0152] Table 2 shows various DL parameters that may be signaled in a DCI, and various options for signaling those parameters to accommodate multiple PDSCHs.

[0153]

[0154]

[0155] Table 2

[0156] In Table 2, the first column indicates the parameter to be referenced. The second column indicates the parameters included in the TDRA table, which can be signaled with reference to the TDRA index parameter included in the DCI. Each remaining column indicates an option for signaling those parameters to accommodate multiple PDSCHs. It should be understood that the options shown are examples, and additional examples are also contemplated.

[0157] Many of the parameters shown in Table 2 also appear in Table 1 and may operate substantially as described in conjunction with Table 1 , except that the parameters shown in Table 2 relate to PDSCH messages, rather than PUSCH messages, as shown in Table 1 .

[0158] Option 1 shows a possible parameter configuration suitable for transmitting multiple PDSCHs consecutive in time.

[0159] The FDRA parameters may include an index to the FDRA table, and the DCI may include the FDRA index to indicate the corresponding frequency domain resources used with the signaled PDSCH, essentially as described in conjunction with Table 1. As previously described, FDRA may use a bitmap to indicate a specific RBG (Class 0 allocation), and may also use RIV (Class 1 allocation). Note that for Class 1 allocation, both "interleaved" and "non-interleaved" mappings may be allowed, as opposed to only "non-interleaved" for the uplink case. As shown in Option 1, the FDRA index may be included once for all PDSCHs signaled by the DCI.

[0160] The TDRA parameter may include an index (e.g., 4 bits) to a TDRA table, substantially as described in conjunction with Table 1. The DCI may include a TDRA index to indicate the corresponding time domain resource used with the signaled PDSCH message. As shown in Option 1, the TDRA index may be included once for all PDSCHs signaled by the DCI.

[0161] However, the TDRA table for PDSCH may include some parameters that are different from the parameters included in the TDRA table for PUSCH. For example, in addition to the SLIV and mapping type, the row of the TDRA table indicated by the TDRA index may include a set of time domain resource parameters such as K0 (e.g., the delay between the DCI and the time slot in which the applicable PDSCH will be transmitted, for example, measured in the time slot) and the demodulation reference signal (DMRS) position (e.g., an indication of the location of the DMRS). These values ​​can be configured by RRC messaging. Because in option 1, the PDSCH is continuous in time, RRC messaging can signal a single K0 value (e.g., for the first PDSCH), and the value of each subsequent PDSCH can follow continuously.

[0162] The MCS1 and MCS2 parameters (e.g., 5 bits each) may operate substantially as described in conjunction with Table 1. DL parameters may include two MCS fields because a DL transmission may include two layers. Similarly, NDI (NDI1 and NDI2), RV (RV1 and RV2), HARQ process number, and DAI parameters may operate substantially as described in conjunction with Table 1.

[0163] A PUCCH resource indicator (PRI) parameter (e.g., 3 bits) may include an index to a predefined PUCCH resource set, e.g., provided via RRC messaging. An entry in a PUCCH resource set indexed by the PRI parameter may identify one or more resources to be used for an associated PUCCH message, e.g., to carry ACK / NACK information for an applicable PDSCH. As shown in Option 1, the DCI may signal a version of the PRI to identify the PUCCH resources to be used with all PDSCHs signaled by the DCI.

[0164] The K1 parameter (e.g., 3 bits) may indicate the delay between the time slot allocated for the PDSCH message transmission and the time slot in which the UE may send ACK / NACK feedback for the PDSCH message. As shown in Option 1, the DCI may signal a version of the K1 parameter for use with all PDSCHs signaled by the DCI. For example, a single K1 parameter may indicate that the corresponding HARQ-ACK transmission is scheduled in K1 time slots after each PDSCH message. As another example, a single K1 parameter may indicate that a single combined HARQ-ACK transmission is scheduled in K1 time slots after the last scheduled PDSCH message.

[0165] The CBGTI parameter may operate substantially as described in conjunction with Table 1. In addition, the DCI may include N codebook group refresh index (CBGFI) parameters (e.g., one parameter for each scheduled PUSCH), where each CBGFI includes one bit per CBG. The CBGFI may indicate whether the applicable CBG is to be refreshed.

[0166] Other DL parameters not shown in Table 2 may also be signaled, for example, by DCI. For example, the DCI may include a priority parameter that may indicate whether a PDSCH or multi-PDSCH transmission is low priority or high priority. For another example, the DCI may include a service request indicator (SRI), precoding information, and layer and / or antenna port indication.

[0167] Option 2 shows a possible parameter configuration suitable for transmitting multiple PUSCHs that are consecutive in time, where the frequency domain parameters can be configured separately for each PDSCH signaled by the DCI. As shown in Option 2, the parameters are the same as those of Option 1, except that the DCI can signal N values ​​(e.g., N FDRA indices) indicating the FDRA configuration, for example, one parameter is used for each PDSCH in the PDSCH signaled by the DCI. This can allow, for example, the frequency hopping configuration to be selected independently for each PDSCH. In some scenarios, the frequency to be used for the first PDSCH signaled by the DCI can be indicated by a normal FDRA index, but the frequency to be used for subsequent PDSCHs (e.g., in a frequency hopping configuration) can be indicated as a frequency offset, for example, using a frequency domain offset table, as discussed further below. This can reduce the overhead required for the delivery of FDRA parameters for each PDSCH signaled by the DCI.

[0168] In some scenarios, the changes to the FDRA parameters included in the DCI shown for Option 2 may be applied in combination with any of Options 3 to 5. For example, Option 2 may be combined with any of Examples 3 to 4 to transmit multiple PUSCHs that are not consecutive in time.

[0169] Option 3 shows a possible parameter configuration suitable for sending multiple PDSCHs that are not restricted to being contiguous in time. Specifically, as shown in Option 3, the parameters are the same as those of Option 1, except that the TDRA table can be configured (e.g., via RRC messaging) to include N (e.g., independent) values ​​of K0, and the DCI can indicate N values ​​of K1. Providing N values ​​of K0 and K1 can allow the TDRA table to include K0 values ​​that are spaced apart in time sufficient to result in non-contiguous PDSCHs, and also allow the TDRA table to signal PUCCH feedback instances for each of these PDSCHs. This can increase the flexibility of scheduling PDSCHs, but can also increase the complexity of the TDRA table and the size of the RRC message.

[0170] In some scenarios, the signaling overhead of providing N values ​​of K1 can be reduced by defining an index table of K1 values. For example, the DCI can include N entries in the index table. As another example, the signaling overhead can be further reduced by configuring the DCI to include a complete entry in the index table, for example, for the first PDSCH, and then signaling the remaining N-1 indices by signaling an offset from the first index. As another example, the table can be configured to include N K1 values ​​so that a single table index can indicate the K1 value for each PDSCH signaled by the DCI.

[0171] In some scenarios, the changes to the K0 parameters shown for option 3 may be applied in conjunction with option 2 and / or any of options 4-5.

[0172] Option 4 shows another possible parameter configuration suitable for sending multiple PDSCHs that are not limited to being continuous in time. Specifically, as shown in Option 4, the parameters are the same as those of Option 1, except that the DCI can signal N values ​​indicating the TDRA table entries, and the TDRA table entries for K2, SLIV, and mapping can each include a single value. For example, the DCI may include a normal TDRA index (e.g., 6 bits) for each of the N PDSCHs to indicate the row of the TDRA table containing the TDRA parameters to be used for the corresponding PDSCH. However, this will increase the size of the DCI by 4*(N-1). Therefore, more efficient signaling may be required. As an alternative example, the DCI may include a normal TDRA index used only for the first PDSCH. For subsequent PDSCHs, the DCI may include an indication of an offset value (e.g., 1 bit or 2 bits) relative to the first TDRA index, for example, as discussed further below. This can reduce the overhead required for TDRA parameter delivery for each PDSCH signaled by the DCI.

[0173] Because each PDSCH in Option 4 can be configured with its own TDRA parameters, the TDRA table does not need to include multiple K0, DMRS position, SLIV, and mapping type parameters on each row. Therefore, each entry for K0, DMRS position, SLIV, and mapping type parameters can contain a single value.

[0174] Additionally, in option 4, the DCI may indicate N values ​​of K1, for example according to any of the examples described in conjunction with option 3.

[0175] In some scenarios, the changes to the TDRA parameters shown for option 4 may be applied in conjunction with any of options 2 to 3 and / or option 5.

[0176] Option 5 illustrates a possible parameter configuration suitable for transmitting multiple PDSCHs that are contiguous in time, where the MCS and PRI parameters can be configured separately for each PDSCH signaled by the DCI. As shown in Option 5, the parameters are the same as those of Option 1, except that the DCI can signal N sets of MCS1 and MCS2 parameters and N PRI parameters, for example, one set for each of the PUSCHs signaled by the DCI. This can allow the MCS configuration to be selected independently for each PUSCH. It can be noted that changing the MCS parameters and PRI parameters together as in Option 5 can be advantageous because both parameters can affect the timing and K1 of the HARQ-ACK feedback.

[0177] In some scenarios, the signaling overhead of providing N values ​​of the PRI can be reduced by including, for example, a first PRI parameter for the first PDSCH in the DCI, and then signaling an offset value from this index for each subsequent PDSCH. For another example, the DCI may only include, for example, the first PRI parameter for the first PDSCH, and the UE may increment the index value for each subsequent PDSCH.

[0178] In some scenarios, the changes to the MCS and PRI parameters included in the DCI shown for Option 5 may be applied in combination with any of Options 2 to 4. For example, Option 5 may be combined with any of Examples 3 to 4 to transmit multiple PUSCHs that are not consecutive in time.

[0179] Additional details regarding the implementation of the previous options for PxSCH parameter signaling will now be discussed.

[0180] Figures 8 and 9 -Time domain enhancement using additional signaling

[0181] As described above, multi-transmission time interval (TTI) PxSCH scheduling can be achieved, for example, by modifying the DCI and / or TDRA table. For example, any of the DCI formats 0_1, 0_2, 1_1, and / or 1_2 can be modified, and / or the TDRA table indexed by any of those DCI formats can also (or alternatively) be modified. Such modifications can allow for the indication of single or multiple non-contiguous PxSCHs in any of the multiple scheduled slots.

[0182] The TDRA table can be configured to include various numbers of PxSCHs in a row. In some scenarios, this number can be based on the subcarrier spacing (SCS) and / or UE capabilities. For example, if the UE is capable of processing X PxSCHs per set of 4 time slots using 960kHz, the TDRA table can be configured to include values ​​for 4X PxSCHs per row. Increasing the number of PxSCHs can increase the amount of memory required to process DCI and / or PxSCH, which can limit UE capabilities. In some scenarios, the UE can signal its capabilities to the BS, and the BS can configure the TDRA table and / or DCI based at least in part on this UE capability.

[0183] As discussed above in conjunction with options 3 to 4 of each of Tables 1 and 2, the TDRA table may be extended to signal parameters for N PxSCHs, which may be discontinuous in the time domain. Figure 8 The first three rows of an example of such a TDRA table for PUSCH are shown, including examples of contiguous and non-contiguous options, according to some embodiments. Figure 8As shown, the TDRA table can provide separate K2, SLIV and mapping type for each PUSCH. Figure 9 The first three rows of an example of such a TDRA table for PDSCH according to some embodiments are shown, including examples of contiguous and non-contiguous options. Figure 9 As shown, the TDRA table can provide a separate K0, DMRS position, SLIV, and mapping type for each PUSCH. In either example, the number of scheduled PxSCHs can be signaled by the number of valid SLIVs, which is included in the row of the TDRA table signaled in the DCI. Therefore, the DCI can signal different numbers of PxSCHs by signaling different TDRA indices. Figure 8 and Figure 9 In the example of , each row indicates 5 scheduled PxSCHs. It should be understood that Figures 8 and 9 The TDRA table for (and other TDRA tables included throughout this disclosure) can be significantly larger (e.g., 64 rows), but for simplicity, only a few rows are shown here.

[0184] In some scenarios, additional signaling may be defined to add further flexibility. As a first example of additional signaling, the DCI may include an additional parameter "M" to indicate the number of entries to be used from the identified row of the TDRA table. For example, in conjunction with Figure 8 The TDRA table indicates that a UL DCI with a value of 3 for the M parameter and a value of 2 for the TDRA index parameter will indicate that 3 PUSCHs are scheduled, with K2 values ​​of 2, 4, and 6. Similarly, Figure 9 A DL DCI indicating a value of 4 for the M parameter and a value of 2 for the TDRA index parameter will indicate that 3 PDSCHs are scheduled, with K2 values ​​of 2, 4, 6, and 8. In either example, a single PxSCH may be signaled by indicating a value of 1 for the M parameter.

[0185] As a second example of additional signaling, the DCI may include an additional parameter "enable / disable" to indicate whether each resource set identified in the signaled row of the TDRA table is enabled or disabled. For example, the enable / disable parameter may consist of an N-bit field (or an M-bit field), where one bit indicates whether the corresponding entry in the signaled row of the TDRA table is enabled. As a specific example, in conjunction with Figure 8The TDRA table indicates that an UL DCI with a value of 1 for the TDRA index parameter and a value of "1,0,1,1,0" for the enable / disable parameter will indicate that three PUSCHs are scheduled, with K2 values ​​of 2, 4, and 5. Using the enable / disable parameter adds greater flexibility by allowing the DCI to dynamically signal both the number and location of PxSCHs to be transmitted from any row of the TDRA table. Furthermore, using the enable / disable parameter allows for more refined retransmission control. For example, in some scenarios, a PDCCH may be scheduled multiple times based on PDCCH reception reliability. For example, it is possible that a PDCCH cannot be reliably received, and the base station may send multiple repetitions of the same PDCCH to the UE to ensure reception. Given that DCI can be carried in the PDCCH, this may imply retransmission of the DCI. In such scenarios, any PxSCHs that have already been transmitted or received by the base station at the time the DCI is retransmitted can be marked as disabled in the retransmitted DCI. In some scenarios, the new DCI may also disable one or more future PxSCHs. In some scenarios, the enable / disable parameter may not be included in a new field, but may be added to an existing field, such as the TDRA index field.

[0186] As a third example of additional signaling, a MAC control element (CE) or other signaling may include an indication to activate or deactivate a subset of rows in the TDRA table. Traditionally, the size (in bits) of the TDRA parameter in the DCI is determined based on the number of rows in the TDRA table, which is configured at a higher layer. For multi-TTI scheduling (e.g., scheduling multiple PxSCHs), the number of rows may increase compared to a single TDRA configuration to accommodate both single-TTI scheduling and multi-TTI scheduling. This additional overhead can be reduced or avoided by allowing the MACCE to deactivate a subset of rows. For example, one or more rows can be deactivated based on the most recent buffer status information for DL ​​and / or UL. With this approach, the TDRA field size can be determined based on the activated TDRA entries rather than all RRC-configured entries.

[0187] As a specific example, a base station can configure a TDRA table with 16 rows, for example, through RRC signaling. In a traditional design, the TDRA field would be 4 bits in size. However, using MAC CE, the base station can select a subset of these rows, for example activating 4 of the 16 rows during a period of time. Thus, the size of the TDRA index parameter can be reduced from 4 bits to 2 bits. It should be noted that this option may sacrifice scheduling flexibility for reduced overhead.

[0188] In some scenarios, the SLIV values ​​shown in Tables 8 to 9 can be from a "master SLIV" table so that the SLIV used for each PXSCH is not randomly selected. This can help avoid very complex HARQ constructions (e.g., for Class 1 codebooks).

[0189] Figures 10 to 13 Time-domain enhancement using reduced signaling

[0190] As described above, for example, in combination with Option 4 of Table 1 and Table 2, the DCI may indicate N TDRA indices. For example, one TDRA index for each PxSCH in the PxSCH signaled by the DCI. However, explicitly including N TDRA indices in the DCI may be inefficient. Thus, in some scenarios, the DCI may explicitly include 1 TDRA index, for example, for the first PxSCH, and then be able to indicate the TDRA indices for the remaining PxSCHs in some more efficient way; for example, in a way that makes the DCI include fewer bits.

[0191] In some scenarios, consistent with Option 4 of Table 1 and Table 2, the TDRA table may be configured such that one or more rows in the table indicate a single value for each applicable parameter (e.g., K2 / K0, SLIV, and mapping type, and the DMRS position for PDSCH).

[0192] Other scenarios may use a combination of Option 3 and Option 4 such that the DCI signals L TDRA indices, where L < N, and the TDRA table is configured such that each row indicates the corresponding J values for each applicable parameter, where J < N. Figure 10 The first three rows of an example of such a TDRA table for PUSCH are shown, where J for the first row is 2 (J - 1 = 2). As shown, J2 = 2 and J3 = 5. These values are merely examples, and other values may be used in various scenarios. Defining a TDRA table with one or more rows having J > 1 allows the DCI to indicate the scheduling of N PxSCHs while including only L indications, which can reduce the signaling overhead in the DCI.

[0193] Regardless of whether each / any row of the TDRA table includes multiple values, the overhead can be further reduced by offset signaling. For example, the DCI may include a normal TDRA index (e.g., 6 bits) to indicate the resource allocation for one or more PxSCHs and then may include one or more index offsets to indicate the resource allocation for the remaining PxSCHs. The index offset may have fewer bits than the TDRA index (e.g., 3 bits).

[0194] For example, Figure 11 shows the possible values mapped to a 3-bit index offset field. Figure 11 This is merely an example, and many other values are possible. As shown, the index offset may include any bit value from 0 to 7. Each bit value may indicate an offset value, the range of which may be from -3 to 4. Each offset value may indicate a differential offset relative to the first TDRA index.

[0195] For example, DCI can use Figures 10 and 11 The DCI may include a 6-bit TDRA index parameter 1 and a 3-bit index offset 4. The TDRA index parameter 1 identifies row 1 of the TDRA table, which indicates K2 values ​​of 2 and 3. Figure 11 The table converts index offset 4 to an offset value of 1. This identifies row 2 of the TDRA table because row 2 is obtained by adding 1 to the row identified by the previous TDRA index parameter. Therefore, in this case, index offset 4 indicates that the K2 values ​​are 5 and 7.

[0196] As an option, the K2 value indicated by the index offset may be relative to the DCI. In this case, the DCI would indicate that the PUSCH is scheduled in slots 2, 3, 5, and 7 after the slot in which the DCI is received. Figure 12 As shown, the DCI is received in slot 0. Therefore, four PUSCHs are scheduled to start at slot 2 (symbol 0), slot 3 (symbol 0), slot 5 (symbol 3), and slot 7 (symbol 5), all of which are in the Figure 10 This is clearly indicated in rows 1 and 2 of the TDRA table shown in FIG.

[0197] As another option, the K2 value indicated by the index offset may be relative to the most recent time slot previously indicated. Figure 13 This option is shown in FIG. As shown, the DCI is again received in time slot 0. As previously mentioned, the TDRA index parameter identifies row 1 of the TDRA table, indicating K2 as 2 and 3, which indicates that two PUSCHs are scheduled after being delayed by 2 and 3 time slots relative to time slot 0. Therefore, the PUSCH is scheduled to start in time slot 2 (symbol 0), time slot 3 (symbol 0), as in Figure 12 In the example, the index offset identifies row 2, indicating that K2 is 5 and 7. However, in Figure 13 In the example of , those K2 values ​​are processed relative to the latest K2 value previously indicated by the DCI. Since the latest K2 value indicated by the TDRA index is 3, the index offset indicates that two additional PUSCHs are scheduled to start at slot 8 (symbol 3) and slot 10 (symbol 5) because those are the positions indicated by K2 of row 2 relative to the K2 value of 3.

[0198] In a slight variation of this option, the K2 value can be processed relative to the latest slot previously indicated by the DCI. Since the latest slot indicated by the TDRA index is slot 3, the index offset indicates that two additional PUSCHs are scheduled to start at slot 8 (symbol 3) and slot 10 (symbol 5). Therefore, in this example, this variation produces the same result as Figure 13However, in other examples, for example, where the DCI includes multiple index offset values, this variation can produce very different results.

[0199] In a further variation of this option, the starting point of the scheduled transmission of PUSCH can be further relative to the SLIV of the previous PUSCH. For example, instead of PUSCH3 starting 5 slots after the slot where PUSCH2 ends, PUSCH3 can start 5 slots after the slot where PUSCH2 starts. Similarly, Figure 13 In this example, this distinction has no effect because PUSCH2 starts and ends in slot 3. However, if PUSCH2 were extended into slot 4, this would cause PUSCH3 to start one slot later than in this example; i.e., slot 9.

[0200] Because K2 values ​​are processed in this manner relative to previously indicated time slots, rows in the TDRA table may be less likely to need to include large K2 values, which can allow the use of smaller TDRA index tables (thereby reducing signaling overhead in DCI and / or RRC signaling) and / or allow additional diversity between the rows of the TDRA table.

[0201] In the DL example, K0 may be similarly processed relative to the DCI or previously indicated PDSCH. K1 may also be processed relative to the DCI or previously indicated PDSCH, or may be processed relative to the location of the associated PDSCH.

[0202] It should be noted that similar differential signaling can be applied to additional fields, such as MCS parameters and / or HARQ process number parameters.

[0203] In another variation, the DCI may include a normal TDRA index (e.g., 6 bits) to indicate resource allocation for one or more PxSCHs, and may subsequently include one or more secondary indices to indicate resource allocation for the remaining PxSCHs. The secondary index may have fewer bits (e.g., 2 bits) than the TDRA index and may be used as a table index in a secondary TDRA table that may be smaller than the standard TDRA table (e.g., four rows). Each row of the secondary TDRA table may include some or all of the parameters included in the rows of the standard TDRA table, but the value may be processed relative to the DCI or the previously indicated K2 or time slot, for example, as described above. The values ​​included in the rows of the secondary TDRA table may be selected to provide versatility in selecting resources relative to the previously indicated PUSCH. For example, a large K2 value may not be needed in the secondary TDRA table because the DCI may signal a PUSCH that starts relatively soon after the previous PUSCH, even if such a PUSCH may be scheduled in a large number of time slots after the DCI.

[0204] In some scenarios, to avoid increasing RRC signaling overhead, the secondary TDRA table may be (or include) a subset of the standard TDRA table. For example, multiple rows of the TDRA table (e.g., the first four rows) may be designated as also serving as the secondary TDRA table. Thus, while the DCI may include a TDRA index indicating any row of the TDRA table to signal the first group of one or more PxSCHs, each subsequent group of one or more PxSCHs indicated by the DCI may be scheduled relative to the previous group of PxSCHs only within the resources indicated by the values ​​in one or more of the four rows of the secondary TDRA table.

[0205] In some scenarios, combined with Figures 10 to 13 The features described can be combined with Figures 8 and 9 The combination of features described.

[0206] Figures 14 to 16 -Frequency domain enhancement

[0207] As described above, multi-TTI PxSCH scheduling may include frequency hopping. As shown in Tables 1 and 2, the DCI may include a single FDRA index, or may include multiple FDRA indices, e.g., for each TTI, each PxSCH, etc. Various options may be employed to provide efficient signaling of the frequency hopping configuration for multi-TTI PxSCH transmission.

[0208] As a first option, the DCI may include a single FDRA indication, such as an FDRA index, which may indicate a frequency hopping configuration that applies to all associated TTIs, resulting in a fixed frequency hopping pattern within each TTI. Figure 14 As shown, the first TB of each TTI can be scheduled at a first frequency, and the second TB of each TTI can be scheduled at a second, different frequency. In this example, each TTI can use the FDRA signaled in the DCI. This can provide equal diversity for each TTI. However, in this configuration, if a single OFDM communication is used (i.e., with only one TB), the TTI may not include frequency hopping.

[0209] As a second option, the DCI may again include a single FDRA indication, which may indicate the frequency hopping configuration that applies to all associated TTIs. However, in this option, each TTI may use a combination of the signaled FDRA and the relative position in the sequence of TTIs to select frequency domain resources. For example, Figure 15 As shown, the TBs for the first TTI (and the third TTI, the fifth TTI, etc.) can be scheduled at a first frequency, and the TBs for the second TTI (and the fourth TTI, the sixth TTI, etc.) can be scheduled at a second frequency. This option can enable TTIs to have different diversity performance, for example, if the performance on one frequency is better.

[0210] As a third option, the DCI may include an FDRA indication for each TTI. This may allow frequency hopping to be used only for those TTIs that are specifically desired. For example, Figure 16 As shown, the DCI may include an FDRA indication for the second TTI but not for the first TTI to include intra-TTI frequency hopping (eg, similar to the first option).

[0211] As a fourth option, the DCI may again include a single FDRA indication to indicate the frequency hopping configuration applied to all associated TTIs. In this option, each PxSCH may be divided into two segments (e.g., equally divided), and frequency hopping may be performed between the two segments. In some scenarios, PxSCHs that are too short may not be split.

[0212] As a fifth option, the PxSCHs in the same time slot can be set to the same frequency position, and the frequency position can be alternating between time slots. This option can help avoid fragmentation of system resources.

[0213] In some scenarios, the frequency used during frequency hopping (or the frequency offset between the first frequency and the second frequency) can be signaled in the DCI, for example, for each PxSCH. For example, the DCI can include an index to a frequency domain (FD) offset table, for example, similar to the offset signaling discussed previously, in order to reduce signaling overhead.

[0214] In some scenarios, frequency offsets can be used instead of predefined frequency hopping. For example, instead of including a flag to activate a predefined hopping configuration, the DCI can include an indication to offset the frequency by some offset, such as relative to the most recent previous frequency or relative to the original frequency. This can increase flexibility because the offset can be implemented on demand and the frequency can be offset to the desired extent. However, this may be achieved at the cost of increased signaling overhead. However, signaling the offset may require less signaling overhead than explicitly indicating the new configuration. For example, this can allow changes to the FDRA without the need for full FDRA information transmission. In order to reduce signaling overhead, the DCI can include an index to a table of offset values.

[0215] In some scenarios, the change in FD resources signaled for a PxSCH may be applied to one or more subsequent PxSCHs, for example, until the end of the TTI, or until the end of multiple PxSCH transmissions.

[0216] In some scenarios, the RRC configuration may be tied to the frequency allocation.

[0217] Capability Definition

[0218] Various implementations of the systems and methods disclosed above may operate using different numbers of PxSCHs per slot / multi-slot.

[0219] As a first option, only one PxSCH is allowed per time slot.

[0220] As a second option, the number of allowed PxSCHs can be variable, for example, based on the SCS and / or UE capabilities. For example, the number of time slots can be fixed, but the number of PxSCHs can be configurable, for example, up to N PxSCHs per 8 time slots when operating at 960 kHz, and up to N PxSCHs per 4 time slots when operating at 480 kHz. The base station can configure up to N PxSCHs per a fixed number of time slots. As another example, both the number of time slots and the number of PxSCHs can be configurable. For example, the number of PxSCHs can be configured to be up to N PxSCHs per M time slots. The base station can configure these values ​​for the UE to determine the TDRA size, for example, based on the UE capabilities.

[0221] Figure 17 -Method for delivering payload data messages

[0222] Figure 17 is a flow chart illustrating an example method for delivering a payload data message according to some embodiments. The method of claim 17 may be performed by a base station in a wireless communication network, such as base station 102, or by a portion thereof, such as processor 404, radio 430, and / or communication link 432. Figure 17 The method shown in is an example, and many variations are possible. For example, in some scenarios, the Figure 17 One or more elements of the embodiment of the present invention may be omitted, and / or additional elements may be added. As a specific example, elements 1702-1706 may be omitted, or elements 1708-1712 may be omitted or performed before, simultaneously with, or interleaved with elements 1702-1706.

[0223] At 1702, the base station 102 may generate a DL control message. In some scenarios, the DL control message may include a DCI. The DL control message may indicate DL transmission resources allocated for multiple payload data messages. For example, the multiple payload data messages may include TBs to be sent on the PDSCH. In some scenarios, the base station 102 may generate a DL control message that indicates the DL transmission resources allocated for the multiple payload data messages at least in part in response to determining that at least one of the multiple payload data messages is to be sent within a particular frequency range (such as above 52.6 GHz). For example, in some scenarios, if the payload data message is to be sent in a lower frequency range, the base station 102 may generate a separate DL control message for each payload data message, e.g., consistent with conventional practice.

[0224] At 1704, base station 102 may send a DL control message, for example, to one or more UEs, such as UE 106. Specifically, base station 102 may send the DL control message to at least one or more UEs to which the plurality of payload data messages are addressed.

[0225] At 1706, the base station 102 may send multiple payload data messages based on the DL control message. For example, the base station 102 may send multiple payload data messages based on the allocated downlink transmission resources, e.g., to one or more UEs to which the payload data messages are addressed.

[0226] In various scenarios, the DL control message can be generated in a configuration consistent with any of the above discussions.For example, in some scenarios, the allocated downlink transmission resources may include transmission resources that are not contiguous in time.

[0227] In some scenarios, the control message may include an indication of the corresponding time domain resources allocated to each of the payload data messages. For example, the indication of the corresponding time domain resources may identify the corresponding start time and duration for each of the payload data messages. In some scenarios, the identification of such start time and duration may take the form of K0 and SLIV values, as discussed above in conjunction with the TDRA table.

[0228] As a specific example, the indication may comprise an index to a DL resource allocation table (such as a TDRA table). The index may indicate a single entry of the table, the single entry identifying the corresponding time domain resource allocated to each of the payload data messages, e.g., as in conjunction with Figure 9 discussed.

[0229] As another example, for each of the payload data messages, the indication may include a corresponding index to a DL resource allocation table (such as a TDRA table). Each index may indicate a different entry of the table, wherein each indicated entry of the table identifies a corresponding time domain resource allocated to the associated payload data message, e.g., as discussed in conjunction with option 4 of Table 2.

[0230] As another example, the indication may include an index to a DL resource allocation table (such as a TDRA table) and at least one offset value. The index may indicate a first entry of the table, and the first entry may identify a corresponding time domain resource allocated to at least a first payload data message in the payload data message. In some scenarios, the first entry of the table may identify a corresponding time domain resource allocated to multiple data messages. Such a table may be similar to a table combined with Figure 10 The at least one offset value may identify the second entry of the table by identifying the position of the second entry relative to the first entry, for example, based on the combination of Figures 10 to 13 Any of the discussed differential offset signaling.The second entry may identify a respective time domain resource allocated to at least a second one of the payload data messages.

[0231] In conjunction with some or all of the examples including the example of indicating entries of a table, each indicated entry of the table may include at least one value indicating a time slot in which the transmission of the corresponding payload data message is scheduled to start. In some scenarios, the time slot may be indicated by specifying a delay between the time slot in which the control message is sent and the time slot in which the transmission of the corresponding payload data message is scheduled to start. For example, the indicated entry may include a K0 value relative to a DCI reference, for example, as in conjunction with Figure 10 and Figure 12 In other scenarios, the time slot may be indicated by specifying a delay between the time slot at which the latest payload data message of the corresponding first payload data message is scheduled to start and the time slot at which each corresponding second payload data message is scheduled to start. For example, the indicated entry may include a K0 value referenced relative to the latest time slot signaled for the previous payload data message, for example, as described in conjunction with Figure 10 and Figure 13 discussed.

[0232] As another example, the indication may include a first index into a first DL time domain resource allocation table (such as a TDRA table) and a second index into a second time domain resource allocation table (such as the secondary TDRA table discussed above). As described above, the first index may indicate an entry of the first table, wherein the entry of the first table may include at least one value (e.g., a K0 value) indicating the time slot in which the transmission of the corresponding first payload data message is scheduled to start by specifying a delay between the time slot in which the control message is sent and the time slot in which the transmission of the corresponding first payload data message is scheduled to start. The second index may be a control message that occupies fewer bits than the first index. The second index may indicate an entry of the second table, wherein the entry of the second table includes at least one value indicating the time slot in which the transmission of the corresponding second payload data message is scheduled to start by specifying a delay between the time slot in which the most recent payload data message of the corresponding first payload data message is scheduled to start and the time slot in which each corresponding second payload data message is scheduled to start.

[0233] In some scenarios, for each of the payload data messages, the control message may indicate a resource allocation for sending an acknowledgement (ACK) feedback message in response to the corresponding payload data message.

[0234] In some scenarios, the control message may include an indication of the frequency hopping configuration for each TTI.In some scenarios, the control message may include any other indication of the frequency hopping configuration discussed above.

[0235] At 1708, the base station 102 may generate an UL control message, such as a DCI. In some scenarios, the DL control message may include the DCI. The UL control message may indicate UL transmission resources allocated for the second plurality of payload data messages. For example, the second plurality of payload data messages may include TBs to be transmitted on the PUSCH. Similarly, in some scenarios, the base station 102 may generate an UL control message for the plurality of payload data messages at least in part in response to determining that at least one payload data message in the second plurality of payload data messages is to be transmitted within a particular frequency range, such as above 52.6 GHz.

[0236] The UL control message may include features similar to any of those discussed above in connection with the DL control message generated at 1702. Additionally, the UL control message may include any of the features included in the foregoing discussion of multiple PUSCH signaling.

[0237] At 1710, base station 102 may send a UL control message, for example, to one or more UEs, such as UE 106. Specifically, base station 102 may send the UL control message to at least one or more UEs to which the second plurality of payload data messages are addressed.

[0238] At 1712, the base station 102 may receive a second plurality of payload data messages based on the UL control message. For example, the base station 102 may receive the plurality of payload data messages based on the allocated UL transmission resources, e.g., from one or more UEs allocated UL grants in the UL control message.

[0239] It should be understood that the various examples above and in the figures may be shown with respect to UL or DL ​​transmissions. These directions are exemplary only. The examples shown / discussed with respect to PDSCH may be similarly applied to PUSCH, vice versa, etc. For example, according to some embodiments, the techniques described with respect to HARQ acknowledgments may be used as implicit indications (e.g., in Figure 15 and Figure 16 (in) can be applied to PUSCH transmission confirmed by the base station.

[0240] By interpreting each message / signal X received by a base station (BS) in the UL as a message / signal X transmitted by the UE, and interpreting each message / signal Y transmitted by the BS in the DL as a message / signal Y received by the UE, any of the methods for operating the BS described herein can serve as a basis for the corresponding method for operating the UE. In addition, the methods described with respect to the UE can be interpreted as methods for the BS in a similar manner.

[0241] In addition to the exemplary embodiments described above, further embodiments of the present disclosure may be implemented in any of a variety of forms. For example, some embodiments may be implemented as computer-implemented methods, computer-readable storage media, or computer systems. Other embodiments may be implemented using one or more custom-designed hardware devices such as ASICs. Other embodiments may be implemented using one or more programmable hardware elements such as FPGAs.

[0242] In some embodiments, a non-transitory computer-readable storage medium may be configured such that it stores program instructions and / or data, wherein the program instructions, if executed by a computer system, cause the computer system to perform a method, such as any one of the method embodiments described herein, or any combination of the method embodiments described herein, or any subset of any of the method embodiments described herein or any combination of such subsets.

[0243] In some embodiments, a device (e.g., BS 102, or UE 106 or 107) may be configured to include a processor (or a group of processors) and a memory medium, wherein the memory medium stores program instructions, wherein the processor is configured to read and execute the program instructions from the memory medium, wherein the program instructions are executable to implement any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset of any method embodiments described herein, or any combination of such subsets). The device may be implemented in any of various forms.

[0244] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly stated to users.

[0245] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.

Claims

1. A method for delivering a payload data message in a wireless communication network, the method comprising: By a base station of the wireless communication network: sending a control message indicating downlink transmission resources allocated for a plurality of payload data messages, wherein the control message includes an indication of respective time domain resources allocated to each payload data message, and wherein the indication includes: an index to a resource allocation table, wherein the index indicates a first entry of the resource allocation table, the first entry identifying the respective time-domain resources allocated to at least a first one of the payload data messages; and at least one offset value, the at least one offset value identifying a second entry of the resource allocation table by identifying a position of the second entry relative to the first entry, the second entry identifying the corresponding time-domain resource allocated to at least a second one of the payload data messages; and The plurality of payload data messages are sent according to the allocated downlink transmission resources.

2. The method of claim 1, wherein the plurality of payload data messages are sent on a physical downlink shared channel (PDSCH).

3. The method of claim 1, wherein the control message is a downlink control indicator (DCI). The method of claim 1 , wherein the allocated downlink transmission resources comprise transmission resources that are discontinuous in time.

5. The method according to claim 1, further comprising: Through the base station: Generating the control message, wherein the generating comprises configuring the control message to include the allocation of the downlink transmission resources for the plurality of payload data messages in response to determining that at least one of the plurality of payload data messages is to be transmitted within a particular frequency range.

6. The method of claim 1, wherein the indication of the respective time-domain resources identifies a respective start time and duration of each of the payload data messages.

7. The method of claim 1 , wherein each indicated entry of the resource allocation table comprises at least one value indicating the time slot in which transmission of the corresponding payload data message is scheduled to start by specifying a delay between the time slot in which the control message is sent and the time slot in which transmission of the corresponding payload data message is scheduled to start.

8. The method according to claim 1, wherein the first entry of the resource allocation table comprises at least one value indicating the time slot in which the transmission of the corresponding first payload data message is scheduled to start by specifying a delay between the time slot in which the control message is sent and the time slot in which the transmission of the corresponding first payload data message is scheduled to start, and wherein the second entry of the resource allocation table comprises at least one value indicating the time slot in which transmission of the corresponding second payload data message is scheduled to start by specifying a delay between the time slot in which the most recent payload data message of the corresponding first payload data message is scheduled to start and the time slot in which each corresponding second payload data message is scheduled to start.

9. The method of claim 1, wherein for each of the payload data messages, the control message further indicates a resource allocation for sending an acknowledgement (ACK) feedback message in response to the corresponding payload data message.

10. The method of claim 1, wherein the control message includes an indication of a frequency hopping configuration for each transmission time interval (TTI).

11. The method according to claim 1 , further comprising: Through the base station: sending a second control message indicating uplink transmission resources allocated for a second plurality of payload data messages; as well as The second plurality of payload data messages is received according to the allocated uplink transmission resources.

12. The method of claim 11, wherein the second plurality of payload data messages are received on a physical uplink shared channel (PUSCH).

13. A base station for transmission in a wireless communication network, the base station comprising: transceiver circuitry configured to transmit and receive wireless communication signals; and A processing circuit coupled to the transceiver circuit, the processing circuit being configured to cause the base station to perform the method according to any one of claims 1 to 12.

14. A non-transitory computer-readable storage medium storing software instructions that, when executed by a processor of a base station in a wireless communication network, cause the base station to perform the steps of any one of claims 1 to 12.

15. A method for delivering a payload data message in a wireless communication network, the method comprising: By a base station of the wireless communication network: sending a control message indicating uplink transmission resources allocated for a plurality of payload data messages, wherein the uplink transmission resources are non-contiguous in the time domain, and wherein the control message includes an indication of respective time domain resources allocated to each of the payload data messages, and wherein the indication includes: an index to a resource allocation table, wherein the index indicates a first entry of the resource allocation table, the first entry identifying the respective time-domain resources allocated to at least a first one of the payload data messages; and at least one offset value, the at least one offset value identifying a second entry of the resource allocation table by identifying a position of the second entry relative to the first entry, the second entry identifying the corresponding time-domain resource allocated to at least a second one of the payload data messages; and The plurality of payload data messages are received according to the allocated uplink transmission resources.

16. The method of claim 15, wherein the indication of the respective time-domain resources identifies a respective start time and duration of each of the payload data messages.

Images