Autonomous uplink transmission in unlicensed new radio spectrum
By introducing the NR-AUL licensing mechanism in unlicensed spectrum, the system supports UEs in autonomously selecting and switching resources. It adopts an asynchronous HARQ process and solves the latency and efficiency problems in existing technologies through UCI and DFI feedback, thus achieving low latency, high reliability and high efficiency autonomous uplink transmission.
Patent Information
- Application Number
- CN202411390507.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2018-09-21
- Filing Date
- 2019-08-08
- Publication Date
- 2025-01-07
AI Technical Summary
In unlicensed spectrum, the existing UE HARQ process relies on synchronous resource allocation, which leads to increased latency and limited system capacity, and the MCS selection efficiency is low, failing to effectively utilize the uncertainty of channel access.
By introducing the NR-AUL licensing mechanism, flexible time and frequency resource allocation is supported, allowing UEs to autonomously select and switch resources. The asynchronous HARQ process is adopted, and feedback is provided through NR-AUL-UCI and NR-AUL-DFI, thereby improving resource utilization efficiency and flexibility.
It achieves low latency, high reliability and high efficiency autonomous uplink transmission, reduces the chance of collisions and improves system capacity and resource utilization.
Smart Images

Figure CN119276434A_ABST
Abstract
Description
[0001] This application is a divisional application of the invention patent application with the application date of August 8, 2019, application number 201980053348.8, and titled "Autonomous uplink transmission in unlicensed new radio spectrum".
[0002] CROSS-REFERENCE TO RELATED APPLICATIONS
[0003] This application claims priority to U.S. patent application S / N 62 / 716,607 filed on August 9, 2018 and U.S. patent application S / N 62 / 734,516 filed on September 21, 2018, both entitled “Autonomous uplink transmission in unlicensed new radio spectrum,” the contents of which are incorporated herein by reference in their entirety. Background Art
[0004] Machine-to-machine (M2M), Internet of Things (IoT), and Internet of Things (WoT) network deployments may include devices such as M2M / IoT / WoT servers, gateways, and hosted M2M / IoT / WoT applications and services. Such network deployments may include, for example, constrained networks, wireless sensor networks, wireless mesh networks, mobile ad hoc networks, and wireless sensor and actuator networks. Summary of the invention
[0005] In the unlicensed spectrum of New Radio, for example, autonomous uplink transmission can be achieved via a variety of means. These include, for example: flexible time resource allocation for autonomous operation; transmission of UL control information content and resource mapping on PUSCH for autonomous transmission; UE-COT sharing to enable ACK / NACK feedback in DL CORESET; autonomous frequency resource selection across BWPs; and BWP switching methods to access autonomous resources.
[0006] Flexible time resource allocation can be supported in the unlicensed spectrum of New Radio by various means. For example, the gNB can configure the UE's NR autonomous uplink (NR-AUL) transmission as RRC-based resource allocation (Type 1 NR-AUL) or DCI-activated resource allocation (Type 2 NR-AUL).
[0007] Similarly, the gNB provides CBG-based ACK / NACK feedback to the UE for NR-AUL PUSCH. Here, the gNB can use code block group (CBG)-based feedback or the gNB can use transport block (TB)-based feedback only when the CBG is NACKed.
[0008] The UE can select the MCS and indicate the MCS through NR-AUL-Uplink Control Information (NR-AUL-UCI) on certain PUSCH transmissions. The gNB can configure the bitmap of NR-AUL resources for the UE through RRC or DCI. The UE can start transmitting NR-AUL PUSCH from multiple OFDM symbols (OS). The UE can indicate the PUSCH duration through NR-AUL-UCI.
[0009] The UE may use the same amount of resources for NR-AUL-UCI on PUSCH regardless of the PUSCH symbol length. The UE may scramble the NR-AUL-UCI using a scrambling sequence that is common to multiple NR-AUL-UCIs so that the gNB can do the scrambling without knowing the UE ID. The data on PUSCH may be scrambled by a UE-specific scrambling sequence. The UE may repeat PUSCH transmissions but may transmit only one NR-AUL-UCI in the first transmission. The UE may set the NRAULTransmissionTimer timer each time a transmission includes repeated NR-AUL PUSCH, and upon expiration, the UE may retransmit the PUSCH. The UE may share the COT with the gNB and may support multiple UL and DL handovers. The RTS-CTS handshake may occur over COT sharing. The UE may transmit RTS as UCI without data on NR-AUL PUSCH resources.
[0010] The gNB can configure aperiodic CORESET with flexible time resources so that the UE can receive control information from the gNB during the COT sharing period.
[0011] The UE may share the COT only on time resources configured with the CORESET. Here, the UE may indicate the CORESET or the search space for the COT by transmitting the CORESET and / or the search space set ID via the NR-A UL-UCI.
[0012] An FDM UE may share the COT with the gNB by allowing COT sharing to occur on pre-configured time resources.
[0013] Frequency resources can be managed for the unlicensed spectrum of New Radio by a variety of means. For example, the UE can autonomously select frequency resources for NR-AUL transmissions. The gNB can configure multiple NR-AUL frequency resources to the UE for each BWP via RRC. The gNB can configure multiple BWPs to the UE via RRC. The gNB can activate multiple BWPs to the UE at a given time.
[0014] Similarly, if the UE's aulResourceSwitchTimer expires on a frequency resource, then it may autonomously switch from one frequency resource to another. The UE may transmit the identity of the frequency resource in the NR-AUL-UCI. The UE may autonomously select a frequency resource for transmission and return to the previous frequency resource after completing the autonomous transmission. The AUE may autonomously select a frequency resource for transmission and the gNB switches the DL BWP to the BWP of that resource accordingly. The UE transmits an S-UL transmission and subsequently transmits a retransmission that is a NR-AUL transmission.
[0015] This article describes enhancements to configured licenses to support multiple repetitions; multiple license configurations to a UE; group license configuration to reconfigure / activate / update multiple licenses at once; switching between configured licenses; frequency and time hopping of UE resources to minimize the chance of collisions.
[0016] A UE may have multiple NR-AUL grants configured with different timing offsets in the frequency resources; the UE selects the grant for which it obtains channel access.
[0017] The UE may use a different interleaving in each repetition of its HARQ process transmission.
[0018] The following enhancements to configured permissions are proposed:
[0019] UE performs back-to-back HARQ process repetition to achieve low latency and high reliability.
[0020] · The UE transmits the HARQ process and its repetitions in a time-interleaved manner.
[0021] • The UE may use a different number of OS allocations to transmit each repetition of the HARQ ID.
[0022] • A UE may be configured with multiple configured permissions.
[0023] Each configured license can have a license ID
[0024] o A set of permissions can belong to a permission group; updates to a permission group apply to all permissions in the group
[0025] οMultiple licenses can be activated / deactivated by activating / deactivating license groups
[0026] οUE can switch from one license in the license group to another
[0027] UE can switch from one grant to another to complete K repetitions
[0028] UE can transmit on one grant and retransmit on another grant
[0029] The UE may support repeated early termination; upon early termination of a HARQ ID, the UE switches to a grant that provides minimal latency to transmit another HARQ process.
[0030] UE can frequency hop and time hop when transmitting HARQ ID and repetition.
[0031] This summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0032] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, which are not necessarily drawn to scale.
[0033] Figure 1 is a timing diagram of an example Type 1 NR-AUL concept for RRC-based NR-AUL grant.
[0034] Figure 2 is a timing diagram of an example Type 2 NR-AUL concept for activation of a DCI-based NR-AUL grant.
[0035] Figure 3A is a timing diagram of example ACK / NACK feedback through NR_A UL-DFI with TB-based 1-bit feedback for N HARQ processes.
[0036] Figure 3B is a timing diagram of example ACK / NACK feedback through NR_AUL-DFI with CBG-based multi-bit feedback for Kmax HARQ processes.
[0037] Figure 4 is a timing diagram of an example where the NR-AUL retransmission carries the CBGTI field if a NACK is available from the gNB.
[0038] Figure 5 is a flow chart of an example process for UE transmission of NR-A UL-UCI with or without CBGTI field.
[0039] Figure 6 is a timing diagram of example NR-A UL-UCI with and without MCS configuration.
[0040] Fig. 7A is a timing diagram of an example of bitmap-based resource allocation, where the offset of the bitmap of the time slot is set to zero.
[0041] Figure 7B is a timing diagram of an example of bitmap-based resource allocation, where (B) the offset of the bitmap of mini-slots of length 7 OS is set to zero.
[0042] Figure 7C is a timing diagram of an example of bitmap-based resource allocation, where the offset of the bitmap of mini-slots of length 4OS is set to 2OS.
[0043] Fig. 8A is a timing diagram of an example of one cycle in which a B-bitmap is mapped to resources and allocated to a search space.
[0044] Figure 8B is a timing diagram of an example of multiple cycles in which a B-bitmap is mapped to resources and allocated to a search space.
[0045] Fig. 9 is a timing diagram of an example dynamic indication of NR-AUL resources through GC-PDCCH.
[0046] Fig.10 is a timing diagram of an example of multiple starting positions for NR-AUL PUSCH transmission within a time slot.
[0047] Fig.11 is a flow chart of an example UE process for performing self-deferment for NR-AUL resource access.
[0048] Fig. 12A is a timing diagram of example NR-AUL PUSCH time resources, where all PUSCH transmissions of a slot length are independent of the starting OS – first OS of PUSCH1 with CP extension.
[0049] Fig. 12B is a timing diagram of example NR-AUL PUSCH time resources, where all PUSCH transmissions of a slot length, regardless of the starting OS, PUSCH1 starts after the OS with CP extension.
[0050] Fig. 12C is a timing diagram of example NR-AUL PUSCH time resources aligning the first transmission with the slot boundary.
[0051] Fig.12D is a timing diagram of example NR-AUL PUSCH time resources, where the last transmission is short because NR-AUL resources are no longer available.
[0052] Fig.12EThis is a timing diagram of an example NR-AUL PUSCH time resource. If slot length transmission is not possible, no PUSCH transmission is performed.
[0053] Fig.13 is a timing diagram of an example using the same NR-UCI resources and mapping for all PUSCH transmission lengths.
[0054] Fig.14A and Fig. 14B is a timing diagram of an example concept of NR-A UL-UCI on PUSCH.
[0055] Fig.15A and Fig. 15B An example of multiple NR-A UL grants with different time offsets is shown.
[0056] Fig.16 An example of CG switching after COT sharing with the gNB is shown.
[0057] Fig.17A is a timing diagram of an example of repetition of NR-AUL PUSCH in a bundle with consecutive retransmissions.
[0058] Fig. 17B is a timing diagram of an example of repetition of NR-AUL PUSCH in a bundle with non-continuous retransmissions.
[0059] Fig.18A is a timing diagram of an example NR-AUL-UCI in a bundle, where the first NR-AUL PSUCH transmission in the COT carries the MCS for all subsequent transmissions.
[0060] Fig.18B is a timing diagram of an example NR-AUL-UCI in a bundle, where the first NR-AUL PSUCH transmission in the bundle indicates repeated MCS and HARQ ID.
[0061] Fig. 18C is a timing diagram of an example NR-A UL-UCI in a bundle, where the repetitions in the bundle do not carry the NR-A UL-UCI.
[0062] Fig.19 is a timing diagram of an example of NRAulTransmissionTimer operation for a repeating bundle.
[0063] Fig. 20 An example of different interleaving in the repetitions of the HARQ process is shown.
[0064] Fig.21 An example is shown of using the same offset in repetitions to avoid UE collisions.
[0065] Fig. 22 An example of a pseudo-random offset for each UE is shown which minimizes the chance of collision. Some repetitions will collide, while others will not.
[0066] Fig.23 is a timing diagram of an example of UE COT shared with gNB in U-DL-UL mode.
[0067] Fig.24 is a timing diagram of an example of a DCI-based trigger for S-UL during a shared COT.
[0068] Fig.25 is a timing diagram of an example RTS-CTS transmission in NR-AUL resources, where RTS is transmitted by the UE in the form of NR-AUL-UCI only on PUSCH.
[0069] Fig.26A is a timing diagram of an example flexible CORESET allocation after sharing COT with CORESET resources after three PUSCH transmissions.
[0070] Fig.26B is a timing diagram of an example flexible CORESET allocation after sharing the COT with the CORESET allocation after four PUSCH transmissions.
[0071] Fig. 27 is a timing diagram of an example in which the UE shares the COT so that the gNB can transmit on the configured CORESET that is periodically monitored by the UE.
[0072] Fig.28 is a timing diagram of an example in which the NR-A UL-UCI indicates the offset of the shared COT resources relative to the current PUSCH transmission.
[0073] Fig.29 is a timing diagram of an example indication of a CORESET / Space Set ID in addition to a slot offset, which identifies the OS for COT sharing if a slot is configured for multiple CORESETs / Search Spaces.
[0074] Fig.30 is a timing diagram of an example of sharing COT resources where FDM UEs periodically occur so that all FDM UEs will share COT with the gNB simultaneously.
[0075] Fig.31A is a timing diagram of an example selection of frequency resources for NR-AUL 20 MHz subband selection.
[0076] Fig.31BAn example selection of frequency resources for NR-AUL 60 MHz sub-band selection is illustrated.
[0077] Fig.32A is a timing diagram of example selection of BWP for NR-AUL.
[0078] Fig.32B is a timing diagram of an example selection of a BWP for nested candidate BWPs.
[0079] Fig.33 is a timing diagram of example autonomous selection of NR-AUL resources for Type 1 configuration.
[0080] Fig.34 is a timing diagram of an example autonomous BWP switching procedure, where both UL and DL BWPs are switched to B2.
[0081] Fig.35 is a timing diagram of an example autonomous BWP switching procedure, where the UE returns to BWP1 after completing NR-AUL transmission on BWP2.
[0082] Fig.36 is a timing diagram of an example of NR-AUL resources activated with autonomous selection for type 2 configuration.
[0083] Fig.37A is a timing diagram of an example configuration of multiple NR-AUL resources with a BWP with overlapping resources.
[0084] Fig.37B is a timing diagram of an example configuration of multiple NR-AUL resources with a BWP, with resources in different subbands of the BWP.
[0085] Fig.38 is a timing diagram of an example of multiple (R1 and R2) NR-AUL resources within a BWP with overlapping frequency resources.
[0086] Fig.39A is a timing diagram of an example of autonomously selecting a new frequency resource when aulResourceSwitchTimer expires, where LBT for the new resource starts after the aulResourceSwitchTimer expires.
[0087] Fig.39B is a timing diagram of an example of autonomously selecting new frequency resources when aulResourceSwitchTimer expires, where LBT for the new resources starts after UE1's COT on R1 expires.
[0088] Fig.40 is a timing diagram of an example retransmission on an autonomously selected resource.
[0089] Fig.41A An example S-UL retransmission in NR-AUL resources is illustrated.
[0090] Fig.41B An example of S-UL retransmission in NR-AUL resources is shown.
[0091] Fig.42A -D shows an example of back-to-back PUSCH transmissions in a mini-slot.
[0092] Fig.43A -C shows an example of interleaved HARQ process IDs where the repetitions are not back-to-back.
[0093] Fig.44 An example is shown where the HARQ repetitions are split into groups, and the HARQ IDs are interleaved between the groups of repetitions.
[0094] Fig.45 An example is shown where the HARQ repetition has a smaller allocation than the first transmission.
[0095] Fig.46 An example is shown where the HARQ repetition has a larger allocation than the first transmission.
[0096] Fig.47 An example of a UE with two configured grants is shown, where CG2 has a relative offset of two time slots from CG1.
[0097] Fig.48 An example of a CG with non-overlapping time resources is shown.
[0098] Fig.49 Examples of sets of CGs providing different offsets are shown. A UE may be configured with all or a subset of these CGs.
[0099] Fig.50 An example of a licensing group parameter configuration is illustrated.
[0100] Fig.51 An example of an RRC configuration of an offset is illustrated, where a subset of grants is activated via DCI.
[0101] Fig.52A An example license group configuration across multiple frequency regions is shown with a sub-band configuration within a wideband BWP.
[0102] Fig.52B An example license group configuration across multiple frequency regions in multiple BWPs is shown.
[0103] Fig.53A An example of using a timer to suspend and resume NR-AUL transmission on a grant is illustrated.
[0104] Fig.53B An example of pausing and resuming NR-AUL transmission on a grant using Resume-DCI is illustrated.
[0105] Fig.54A An example method of pausing NR-AUL on a grant using a timer is illustrated.
[0106] Fig.54B An example method for suspending NR-AUL on a grant using resume DCI is illustrated.
[0107] Fig.55A An example of a pause during an ongoing NR-A UL transmission when the pause is received is illustrated, wherein the DCI transmission is immediately interrupted.
[0108] Fig.55B An example of a pause during an ongoing NR-AUL transmission when the pause is received is illustrated, where the DCI transmission is interrupted at a slot boundary.
[0109] Fig.56 An example of transmitting missed repetitions by switching to a different CG is illustrated.
[0110] Fig.57 An example is illustrated where the UE does not transmit on CG1 while waiting for a missed repetition on CG5 to complete.
[0111] Fig.58 An example is illustrated in which the UE switches CG to transmit a missed repetition and a subsequent repetition.
[0112] Fig.59 An example of repeating the same RV at the time of switching is illustrated.
[0113] Fig.60A The diagram illustrates an example where the UE switches CG to start transmission of a new HARQ ID upon early termination, where an ACK is received after the third transmission in a repetition bundle.
[0114] Fig.60B The diagram illustrates an example where the UE switches CG to start transmission of a new HARQ ID upon early termination, where an Ack is received after the second transmission.
[0115] Fig.61 The diagram illustrates an example of retransmission when timers on different CGs expire.
[0116] Fig.62 An example of frequency hopping for repetition to minimize collisions is illustrated.
[0117] Fig.63 An example of time hopping of a HARQ process ID with a repetition set is illustrated.
[0118] Fig.64 An example of HARQ process randomization within Pharq is illustrated.
[0119] Fig.65 An example of time hopping across HARQ process IDs and repetitions is illustrated.
[0120] Fig.66 An example of HARQ ID and RV randomization across Ptotal is illustrated.
[0121] Fig.67 An example of sensing-based CG selection is illustrated.
[0122] Fig.68A An example of UE sensing to determine available CGs is illustrated, with a common self-extension value across CGs.
[0123] Fig.68B An example is illustrated of UE sensing to determine available CGs, where each CG generates a self-extension value.
[0124] Fig.69A The diagram illustrates an example in which a UE obtains channel access to a CG for a certain duration - a fixed time T.
[0125] Fig.69B An example is illustrated in which a UE obtains channel access to a CG for a certain duration - timer-based access.
[0126] Fig.70 An example is illustrated in which, once channel access is obtained, no channel sensing is required in CG resources.
[0127] Fig.71 An example UE process for selecting a configured grant to transmit a HARQ process, receiving feedback, and retransmitting the HARQ process in case of a negative acknowledgement is illustrated.
[0128] Fig.72 An example communication system is illustrated.
[0129] Fig.73 is a block diagram of an example apparatus or device configured for wireless communications, such as, for example, a wireless transmit / receive unit (WTRU).
[0130] Fig.74 is a system diagram of a first example radio access network (RAN) and core network.
[0131] Fig.75 is a system diagram of a second example radio access network (RAN) and core network.
[0132] Fig.76is a system diagram of a third example radio access network (RAN) and core network.
[0133] Fig.77 is a block diagram of an exemplary computing system in which one or more devices of a communication network may be implemented, such as certain nodes or functional entities in a RAN, a core network, a public switched telephone network (PSTN), the Internet, or other networks.
[0134] Autonomous retransmission
[0135] The UE starts a timer when it transmits a PUSCH TB for the first time. If the UE does not receive feedback before the timer expires, it can retransmit autonomously. This ensures that if the eNB does not receive the TB, the UE can try to retransmit again on AUL resources.
[0136] Operation in unlicensed spectrum
[0137] In unlicensed operation, the Listen Before Talk (LBT) procedure is defined as a mechanism by which a device can apply a Clear Channel Assessment (CCA) check before using a channel. Clear Channel Assessment (CCA) utilizes at least energy detection to determine if there are other signals on the channel to determine if the channel is occupied or idle, respectively. Depending on the type of channel access, the maximum time a device can use a channel is the "Maximum Channel Occupancy Time (MCOT)", after which it releases the channel.
[0138] Frame structure type 3
[0139] In 3GPP LTE Release 13, frame structure type 3 was introduced for LAA auxiliary cell operation with normal cyclic prefix. The subframes of this frame can be used for uplink / downlink transmission or can be empty. LAA transmission can start and end in any subframe and can consist of one or more consecutive subframes in a transmission burst.
[0140] Configuration License (CG) in NR Release 15
[0141] 3GPP New Radio Release 15 supports two types of configured grants (CGs). In Type 1 CG, RRC configures periodicity, offset, time-frequency allocation, UE-specific DMRS configuration, MCS / TBS, repetition, power control, etc. for the UE. In Type 2 CB, similar to SPS in LTE-A, RRC configures periodicity, power control, and repetition for the UE, while the activation DCI provides offset, time-frequency allocation, MCS / TBS, UE-specific DMRS configuration, etc.
[0142] CG supports both slot-based and mini-slot-based transmissions. In addition, it supports synchronous HARQ transmissions, for example, the HARQ process ID and RV are implicitly indicated by the resource. Retransmissions can occur through scheduled grants. If a transmission is configured, then the transmission can be repeated and can occur until an ACK is received in the form of a scheduled grant or until the maximum number of configured repetitions is completed.
[0143] configuredGrantTimer is configured to the UE to manage CG related procedures. See Chairman Notes AH1801, 3GPP TSG-RAN WG2 meeting, Vancouver, Canada, January 2018. configuredGrantTimer is started / restarted on a PUSCH transmission using a configured grant or on reception of a dynamic UL grant whose associated HARQ process is a HARQ process pre-configured for a configured grant. Only the first transmission in a repetition bundle will (re)start the configuredGrantTimer.
[0144] Autonomous UL transmission in LTE feLAA Release 15
[0145] The 3GPP LTE feLAA Release 15 work item on "Enhancements for LTE operation in unlicensed spectrum" introduces LTE frame structure type 3 with flexible start and end positions in the subframe. The work item also introduces autonomous UL (AUL) transmissions using type 3 frame structure, where the UE selects the MCS and transmits the PUSCH in an asynchronous HARQ process. The UE also transmits AUL-Uplink Control Information (AUL-UCI) to indicate the MCS, UE-ID, HARQ process, and RV for PUSCH transmission. AUL Downlink Feedback Information (AUL-DFI) is introduced to provide explicit ACK / NACK feedback from the gNB to the UE for AUL transmissions.
[0146] MCOT Share
[0147] A UE supporting AUL may obtain the MCOT and allow the eNB to share the COT to transmit the AUL-DFI to the UE. The last symbol of the AUL burst may be dropped to allow the eNB to sense the channel and transmit within the UE's COT. The AUL-UCI carries 1 bit to indicate whether the subframe supports COT sharing. If the UE indicates that the subframe is suitable for UL to DL COT sharing, the UE shall stop its AUL PUSCH transmission in the previous subframe at symbol #12, regardless of the RRC configuration for the PUSCH end symbol.
[0148] The eNB may also allow AUL on UL subframes within the COT of the eNB. A 1-bit field in C-PDCCH indicates whether AUL can share the COT with the gNB.
[0149] Flexible time resource allocation
[0150] The UL grant may be configured via a bitmap rather than just by periodicity. This provides the UE with greater transmission flexibility since the UE can find opportunities for the UE to transmit PUSCH based on its configured period without waiting for delays in the opportunity.
[0151] Multiple CAT4 LBT transmission, no need to wait for feedback
[0152] In the case of scheduled UL, CAT4 LBT transmissions can only occur when a grant is received. However, in AUL, CAT4 LBT transmissions can occur without a grant; thus, multiple consecutive CAT4 LBT AUL transmissions can occur without intermittent grants or feedback.
[0153] Limitations of configured licensing from an NR-U perspective
[0154] Due to the uncertainty of channel access, since the HARQ process is synchronous, the UE may have to wait for a long time to obtain the resources corresponding to the HARQ buffer that it has data to send.
[0155] Furthermore, in CG, retransmissions rely on scheduled grants - this means that LBT at both the gNB and UE are retransmitted on scheduled resources. This increases latency and impacts system capacity.
[0156] In addition, only Type 2CG supports transmission adaptation, which can be done by activating DCI. In unlicensed systems, activating DCI is less efficient than allowing the UE to autonomously select the MCS based on its channel conditions.
[0157] Since many features of LTE feLAA AUL can be applied to NR-U, it was decided in the 3GPP RAN1 93 meeting that five modifications to the configured grant process might be considered. The first is to remove the dependency of the HARQ process information on timing. The second is to introduce UCI on PUSCH to carry HARQ process ID, NDI, RVID. The third is to introduce downlink feedback information (DFI), which includes HARQ feedback for configured grant transmissions. The fourth is the increased flexibility of time domain resource allocation for configured grant transmissions. The fifth is to support retransmissions without explicit UL grants. See Chairman Notes of 3GPP TSG-RAN WG1 meeting #93 held in Busan, South Korea in May 2018.
[0158] NR Bandwidth Part (BWP) Operation
[0159] 3GPP New Radio Release 15 introduces the concept of bandwidth part (BWP). Here, the reception and transmission bandwidth of the UE can be set as a fraction of the total bandwidth of the cell and can be dynamically adjusted to meet the capacity requirements and power saving requirements of the UE. For example, the UE can operate on a narrow BWP during low activity periods to save power.
[0160] A serving cell can be configured with up to four BWPs and there is always one active BWP at any point in time for an activated serving cell. The gNB can instruct the UE to switch to a different BWP via DCI. The UE runs the BWPInactivityTimer in its active BWP. On expiration, the UE switches to the default BWP.
[0161] BWP and channelization
[0162] The following agreement was reached in the 3GPP New Radio RAN1#92bis meeting. See the Chairman Notes of the 3GPP TSG-RAN WG1 meeting #92bis, Sanya, China, April 2018.
[0163] At least for frequency bands where the absence of Wi-Fi cannot be guaranteed (eg, due to regulations), LBT may be performed in units of 20 MHz.
[0164] The 3GPP New Radio study item (SI) on NR-U will further study the details on how to perform LBT on a single carrier with a bandwidth greater than 20 MHz (e.g., an integer multiple of 20 MHz).
[0165] This supports an operation mode where the BWP of a UE in NR-U can consist of one or more 20 MHz bandwidths depending on channel availability.
[0166] BWP switching for NR-U
[0167] In NR, when switching BWP, the UE may have to re-tune to the frequency of the new BWP. The time to make this switch is called the switching delay and is one of the following values: 400us, 600us, 950us, or 2000us. See R2-1810579, "Discussion of BWP operation in NR-U", Huawei, 3GPP TSG-RAN WG2 Meeting #AH-1807, July 2018, Montreal, Canada.
[0168] BWP switching is attractive for NR-U because the UE can switch to a BWP for which LBT is successful.
[0169] However, handover latency can be significant for NR-U deployments since the UE may not be able to switch quickly enough to a BWP whose channel is available. The following enhancements have been proposed to improve BWP operation. See ETSI EN 301.893, 5 GHz RAN; Harmonised Standard, which covers the essential requirements of clause 3.2 of Directive 2014 / 53 / EU V2.1.1, 2017-05
[0170] Option 1: One active wideband BWP with multiple channels can be activated for the UE. There can be multiple parallel LBT processes for different channels within the BWP. The actual transmission bandwidth can be selected as the set of adjacent subbands with successful LBT. Therefore, dynamic bandwidth adaptation can be supported in this active wideband BWP.
[0171] Option 2: Similar to carrier aggregation in LTE LAA, multiple non-overlapping BWPs can be configured for a UE within a wide component carrier. To maximize BWP utilization efficiency, the BWP bandwidth can be the same as the bandwidth of the subband used for LBT. The UE can support multiple active BWPs and transmit on the BWP on which it has successful LBT.
[0172] Example Challenge - Temporal Resource Management for Autonomous NR-U Transmissions
[0173] According to the RAN1#93 agreement, SI will consider providing greater flexibility for the time domain resource allocation of UE. In addition, the allocation must be such that both TDMed and FDMed UEs can be supported. Therefore, given the MCOT constraints of the UE, processes and methods that enable efficient time domain resource usage are required. For example, this can include: flexible autonomous resource allocation indication and COT sharing with gNB; autonomous HARQ transmission and indication; and autonomous retransmission.
[0174] Example Challenge - Autonomous Selection from Multiple Frequency Resources
[0175] As CG operation of NR is developed for NR-U, it is possible to consider allowing the UE to autonomously select frequency resources for transmission based on channel availability. To support this, the configuration of multiple NR-AUL resources for the UE and the mechanism for repetition and retransmission on multiple resources can be defined.
[0176] Example Solution
[0177] In the following discussion, we use the term “New Radio – Autonomous Uplink” (NR-AUL) to refer to autonomous (uplink) UL transmissions by NR UEs on unlicensed spectrum.
[0178] Advanced features of NR-U AUL
[0179] 3GPP NR-U is considering autonomous asynchronous UL transmission, where the UE can select HARQ related parameters on its NR-AUL grant and transmit a UL control signal "NR-AUL-UCI" multiplexed on the NR-AUL PUSCH to the gNB to indicate the HARQ information and potentially other information (such as the UE's ID). The gNB can transmit DL control information "NR-AUL-DFI" to provide explicit HARQ ACK / NACK feedback to the UE on the NR-AUL transmission. NR also considers retransmission of TBs on NR-AUL resources.
[0180] In the following discussion, the term CCA refers to the 25 μs channel sensing used in LTE LAA.
[0181] Type 1 NR-AUL configuration
[0182] We propose in this paper to support an AUL mode of operation for NR-U, where AUL resource parameters are configured to the UE via RRC. Based on the RRC configuration, resources are autonomously activated to the UE when the channel is available. In this mode of operation, no explicit activation is required. The UE uses the autonomous grant only when it has data to transmit; otherwise, it does not use the grant. This configuration is particularly useful for mMTC devices, as they typically have small amounts of data to transmit and the explicit activation overhead can be significant.
[0183] Figure 1 The concept of Type 1 NR-AUL grant is illustrated, where the gNB configures time and frequency resources for the UE through RRC signaling. When the UE needs to transmit NR-AUL PUSCH, it performs LBT and gains access to NR-AUL. The LBT can be CAT4 LBT with a random backoff given by the contention window size (CWS) of the priority class for channel access. Under the following conditions, the UE stops NR-AUL transmission in a given channel access.
[0184] UE's COT expires
[0185] Even if the MCOT of the UE has not expired, the NR-AUL resources are terminated. Figure 1 In the example, since NR-AUL resources are no longer available to it, UE1 releases the channel in time slot #5 after NR-AUL transmission.
[0186] If the UE performs other transmissions on NR-AUL resources, such as S-UL (Scheduled Uplink) PUSCH grants, it performs S-UL instead of NR-AUL transmissions. Here, the S-UL grant may have partial or full resource overlap in time with the NR-AUL grant. Figure 1 In the example, UE1 has S-UL in time slot #7, which is a NR-AUL resource; since NR-AUL resources are not available in the adjacent OS, UE1 performs S-UL and releases the channel.
[0187] Type 2 NR-AUL configuration
[0188] We propose in this paper to support an AUL operation mode for NR-U, where certain AUL resource parameters are configured to the UE via RRC signaling. The gNB transmits an activation DCI to the UE to activate the resources, on which the UE may transmit on NR-AUL resources if the UE has data to transmit. The gNB may transmit a deactivation DCI to the UE to deactivate the resources, on which the UE may not transmit on those NR-AUL resources. This concept is described in Figure 2 Activation DCI may provide MCS, time and frequency resources for transmission. When activated, the UE transmits NR-AUL PUSCH only when it has data to send.
[0189] Under the following conditions, the UE's NR-AUL PUSH transmission ends on type 2 resources.
[0190] UE's COT expires
[0191] Even if the MCOT of the UE has not expired, the NR-AUL resources are terminated. Figure 1 In the example, since NR-AUL resources are no longer available to it, UE1 releases the channel in time slot #5 after NR-AUL transmission.
[0192] Alternatively, the UE may be deactivated so that it loses permission; Figure 2 In , deactivating DCI deactivates the grant after time slot #7.
[0193] If the UE is performing other transmissions on NR-AUL resources, such as an S-UL (Scheduled Uplink) PUSCH grant, it performs S-UL instead of NR-AUL transmissions. Figure 2 In the example, UE1 has S-UL in time slot #7, which is a NR-AUL resource; since NR-AUL resources are not available in the adjacent OS, UE1 performs S-UL and releases the channel.
[0194] CBG-based feedback and retransmission
[0195] NR-AUL-DFI will be transmitted by the gNB to the UE to provide ACK / NACK feedback similar to AUL-DFI of LTE feLAA. However, unlike LTE, NR supports CBG-based feedback. Since CBG-based feedback and retransmission improves resource efficiency (since only erroneous CBGs need to be retransmitted), we propose the following to allow NR-AUL-DFI to provide enhanced ACK / NACK feedback in the following way.
[0196] TB-based feedback: NR-AUL-DFI (from gNB to UE) carries 1-bit ACK / NACK feedback per TB for N HARQ processes in the form of a bitmap, where each bit in the bitmap maps to one HARQ process. N may correspond to all HARQ processes configured for the UE, including those not configured for NR-AUL transmission.
[0197] CBG-based feedback: Multi-bit CBG-based feedback (from gNB to UE) for each TB of K HARQ processes, and an indication of the ID of the kth HARQ process. 1-bit ACK / NACK feedback is provided for each CBG in each TB of a HARQ process. The UE can receive up to K CBGs in a single DCI. max The feedback of HARQ ID. <K max When K>K, the UE may set the bits to zero for the fields with ID>K. max The gNB may transmit multiple NR-AUL-DFIDCIs to the UE, which will detect them at different candidate positions within the search space.
[0198] The HARQ ID for the procedure supported by NR-AUL-DFI is configured to the UE by RRC.
[0199] Note that the number of CBGs per TB has been configured to the UE via RRC.
[0200] In addition, K max Can be configured to the UE by RRC.
[0201] A one-bit field dfiType in the NR-AUL-DFI can indicate whether it carries TB-based feedback or CBG-based feedback, so that a common length and a common RNTI can be used for the DCI. (Zero padding can be used to ensure that the DCI has the same length). This keeps the blind decoding complexity within an acceptable level for the UE. The length and format of the NR-AUL-DFI can be the same as the activation / deactivation DCI of type 2CG; in addition, all DCIs related to NR-AUL operation (activation / deactivation, NR-AUL-DFI) can use a common RNTI, such as a CS-RNTI or a UE-specific NR-AUL-RNTI configured by RRC.
[0202] Figure 3A and Figure 3B An example is shown where dfiType=0 is interpreted as TB-based feedback, while dfiType=1 is interpreted as CBG-based feedback. When decoding the DCI, the UE determines the type of feedback - TB-based or CBG-based - from the dfiType.
[0203] For example, the UE may be configured by RRC to support TB-based transmission and retransmission, CBG-based transmission and retransmission, or both.
[0204] When configured for CBG based communication, if the gNB provides CBG based feedback for the NR-AUL HARQ process and at least one bit indicates NACK, the UE retransmits the NR-AUL PSUCH only with the NACKed CBG.
[0205] The UE also transmits a Code Block Group Transmission Indication (CBGTI) field in the NR-AUL-UCI; the CBGTI has one bit for each CBG in a transmission. The UE sets the bit corresponding to the CBG in a transmission or retransmission so that the gNB can process the PUSCH without ambiguity in identifying the CBG in the PUSCH.
[0206] If the gNB provides TB-based feedback only for the HARQ process and it is NACK, then the UE retransmits the entire TB. The UE may set all bits of the CBGTI to 1 to indicate transmission of the entire TB. Alternatively, the UE may not transmit the CBGTI field in the retransmitted NR-A UL-UCI - this allows keeping the amount of UL control overhead limited and improving coverage.
[0207] In one example, for an initial transmission, the NR-AUL-UCI may not contain the CBGTI field. However, in a retransmission, the NR-AUL-UCI may contain the CBGTI field. Therefore, the length of the NR-AUL-UCI may be different for the initial transmission and the retransmission. Despite this, the gNB does not know whether the received PUSCH carries the NR-AUL-UCI with or without the CBGTI field, for example, it does know the length of the NR-AUL-UCI. Therefore, it blindly decodes two possible NR-AUL-UCI lengths to receive the control information – one without the CBGTI field and the other with the CBGTI field. The successful assumption indicates the TB / CBG content of the PUSCH to the gNB.
[0208] This concept is Figure 4 , where UE1 transmits NR-AUL PUSCH HARQ IDs #0, #1, #2 and #3 with new data on TB; NR-AUL-UCI does not carry CBGTI field and all CBGs are present. UE receives feedback on NR-AUL-DFI indicating CBG-based NACK for some CBGs on HARQ processes #0, #2. When UE1 accesses NR-AUL resources again, it retransmits IDs #0 and #2 with only the NACKed CBGs and indicates those CBGs in the retransmission through the CBGTI field in the NR-AUL-UCI of IDs #0, #2.
[0209] exist Figure 5 An example process for transmission of UE NR-A UL-UCI is shown in FIG.
[0210] Alternatively, the UE may always transmit the CBGTI field in all NR-A UL-UCI (including the first transmission) so that the decoding complexity at the gNB is minimized, but this comes at the expense of increased control signaling overhead.
[0211] Autonomous MCS selection
[0212] In Type 1CG in NR, the MCS is configured to the UE by RRC; in feLAA AUL, the MCS is transmitted to the UE via activation DCI, but the UE can also autonomously select its MCS value and indicate it to the gNB via AUL-UCI.
[0213] For Type 1 NR-AUL, we propose in this paper to support autonomous MCS selection by the UE. The RRC configuration may include a default MCS value, but the UE may choose to override it based on the SINR perceived on the UL channel. The UE reports the selected MCS value to the gNB via the NR-AUL-UCI. The gNB identifies the DMRS and becomes aware of the presence of the AUL PUSCH; further, it decodes the NR-AUL-UCI. After successfully decoding the NR-AUL-UCI, the gNB obtains the MCS value and HARQ parameters to decode the data on the PUSCH.
[0214] In another example, the gNB may configure a subset of possible MCS values to the UE via RRC signaling. The UE may autonomously select one of the configured values and indicate it via the NR-A UL-UCI. Since fewer bits are required to indicate the index of the subset, the payload is reduced due to the MCS bits in the control information.
[0215] The MCS bits (usually indicated by 5 bits) can be a significant part of the NR-AUL-UCI payload (maybe around 25 bits), and the NR-AUL-UCI can take up a lot of resources, especially for small data PUSCH. Therefore, in this paper we propose to selectively indicate the MCS through the NR-AUL-UCI, for example, some PUSCH transmissions carry this field and some PUSCH transmissions do not. The gNB knows the expected size of the UCI payload with MCS and the expected size without MCS. Therefore, it blindly decodes the NR-AUL-UCI for these two hypotheses – without MCS bits and with MCS bits. The successful hypothesis will determine the MCS used to decode the PUSCH.
[0216] Consider an example where the initial transmission in NR-AUL-PUSCH uses the MCS configured by RRC. If it is NACKed or the UE does not receive feedback for a long time, it can retransmit on Type 1 AUL resources with the MCS selected by the UE, which is then indicated in the NR-AUL-UCI. This allows the UE to adapt the MCS to the channel conditions.
[0217] Consider another example where the UE is configured with an NR-AUL grant, where the UE may repeat the PUSCH transmission repK times. In this case, the UE may transmit the MCS only in the first PUSCH in the bundle. The remaining PUSCHs may use the same MCS without explicitly carrying the MCS bits.
[0218] Figure 6Example NR-A UL-UCI with and without MCS configuration is illustrated. In slot #1, the MCS has been configured by RRC and indicated in the NR-A UL-UCI; in slot #5, the MCS is selected by the UE and indicated by the NR-A UL-UCI.
[0219] Time resource allocation for NR-AUL
[0220] We propose in this paper that the UE can transmit NR-AUL PUSCH on resources for which NR-AUL resources are configured and the slot format for OFDM symbols (OS) is indicated as either "F" or "U". The configuration of "F" or "U" alone does not indicate NR-AUL resources, as the gNB can use these resources for scheduled grants. Therefore, explicit NR-AUL time resources should be configured. This can be done in the following way.
[0221] Non-periodic resource allocation
[0222] A B-bit bitmap of NR-AUL time resources can be configured to the UE. feLAA uses a similar AUL configuration where each bit represents a timeslot. Since NR supports more flexibility, we propose in this paper that for a given numerology, one bit in the bitmap can correspond to an NR-AUL resource on N consecutive OSs. The bitmap can indicate AUL grants for resources in L frames. N is configured by RRC. N=2, 4, 7 and 14 are good choices to support mini-slots and timeslot configurations in NR. The first bit of the bitmap is applied to the first N OSs, followed by an F OS offset due to SFN, whose mod(SFN, L)=0, where F<14 OS is also configured by RRC. The offset F allows fine-tuning the position of the resource within the timeslot; this is particularly useful if the resource must start after the position of some critical signal (such as a DL SSB whose resources are not aligned with the timeslot boundary).
[0223] Given that the PBCH TTI is 80 ms, L=8 (8 10 ms frames) may be a good choice for indication via the bitmap since the SI remains unchanged during this period.
[0224] exist Fig. 7A , 7B The bitmap-based resource allocation concept for different values of N and F is shown in 7C.
[0225] Periodic resource allocation
[0226] The UE may be configured with periodic NR-AUL time resources with repetitive opportunities in resource bundles similar to Type 1 and Type 2 CGs in NR. In these configured grants, resources for PUSCH transmission are allocated in a continuous manner. The UE may also be configured with multiple such configured grants, where at least the time resources may be different between grants. In addition, the number of continuous time resources for PUSCH may also be different between grants. Depending on where the UE obtains channel access, the UE selects an appropriately configured grant for PUSCH transmission. This selection may be based on the resource that gives the lowest transmission latency after channel access.
[0227] Time resource configuration for Type 1 and Type 2 NR-AUL
[0228] Depending on the traffic, one type of resource (periodic or aperiodic) can have more advantages than the other. For example, aperiodic configuration allows flexibility in providing AUL resources in complex frame structures with multiple UL and DL switching; it is well suited for burst transmissions of eMBB. Periodic configuration is well suited for URLLC and mMTC because resources can be acquired periodically.
[0229] In order to exploit the possibility of both resource allocations, we propose in this paper that both configurations can be provided to the UE and a 1-bit field aulTimeResourceType can be used to indicate the configuration to be used.
[0230] Type 1 NR-AUL shall have the RRC configured bitmap for aperiodic resource indication. aulTimeResourceType RRC configures to the UE.
[0231] Type 2 NR-AUL can have one of the following configurations. aulTimeResourceType is indicated by the activation DCI:
[0232] • The bitmap for aperiodic resources is configured by RRC.
[0233] · By activating the DCI to indicate the bitmap used for aperiodic resources. This approach can make the DCI larger if the bitmap covers a pattern used for multiple frames.
[0234] GC-PDCCH indication of NR-AUL resources
[0235] Currently, GC-PDCCH is used to dynamically indicate the slot format in NR. The DCI uses format 2_0 with SFI_RNTI scrambling. The gNB can indicate the format for several slots in a single DCI.
[0236] In this paper, we propose to introduce GC-PDCCH in NR-U to dynamically indicate NR-AUL resources.
[0237] The indication is in the DCI of GC-PDCCH and is in the form of a B-bit bitmap, where each bit corresponds to N consecutive OSs. When a bit is set, it indicates NR-AUL resources for N OSs. B can be configured to the UE by RRC.
[0238] The UE may interpret the bitmap in the following manner.
[0239] N can be given directly to the UE via RRC.
[0240] The bitmap may indicate the resources in the current and next period of the search space carrying the indication. Therefore, the UE may interpret each bit in the bitmap as indicating a set of NOS=floor(NumOSinP / B), where NumOSinP corresponds to the number of OSs in the space set over a period of time. Fig. 8A An example is shown in which N is calculated by allocating B bits to resources within 1 cycle of the search space.
[0241] Alternatively, the indication may be for M periods of the search space, with the B / M bits indicating the resources used for each period. The value of M is configured by the gNB. Figure 8B An example is shown in which N is calculated by allocating B bits to resources within 1 cycle of the search space.
[0242] Fig. 9 An example where the gNB shares its COT with the UE is shown in . The gNB obtains the COT after CAT 4 LBT and transmits the GC-PDCCH indicating the NR-AUL resources in the remaining COT.
[0243] The GC-PDCCH may be scrambled with a UE-specific NR-AUL-RNTI which is also used for NR-AUL-DFI and activation or deactivation in a Type 2 configuration; this is intended to provide NR-AUL resources to a specific UE.
[0244] Alternatively, the GC-PDCCH may be transmitted using a "GC-AUL-RNTI" (Group Common-AUL-RNTI), which may be configured for multiple UEs and may be different from the UE-specific NR-AUL-RNTI; here, multiple UEs receive dynamic NR-AUL resource grants. This DCI may be transmitted in an existing DCI format such as format 2_0 and may have the same length as a DCI scrambled with SFI_RNTI, thereby minimizing the blind decoding overhead of the UE.
[0245] If the resources (one or more OS) indicated for NR-AUL by RRC signaling or DCI correspond to DL signaling (such as SS / PBCH or (discovery signal) DRS), the UE assumes that the resources are DL and are not available for NR-AUL.
[0246] If the resources (one or more OS) indicated for NR-AUL through GC-PDCCH overlap with the resources configured as "D" through RRC signaling, the UE may assume that the resources are available for NR-AUL.
[0247] If the resources indicated for NR-AUL via RRC signaling or activation DCI overlap with resources configured as “D” via SFI-RNTI based DCI, the UE may assume that the resources are DL and are not available for NR-AUL.
[0248] If the resources (one or more OS) indicated for NR-AUL via RRC signaling or activation DCI overlap with the resources configured as "D" via RRC signaling, then the UE may take the transmission direction based on the use case. For example,
[0249] • If the UE has configured CORESET on those resources, then DL transmissions can be expected on those resources.
[0250] If the UE does not configure a CORESET on those resources, it may be assumed that the resources are available for NR-AUL transmission.
[0251] NR-AUL PUSCH multiplexing
[0252] In AUL feLAA, all TDMed UEs using PUSCH resources in all interlaces randomly select a self-deferment value from a preconfigured list; the deferment is applied to OS#0 in the subframe so that PUSCH transmission can start from OS#1. If the channel is idle before the deferment is completed, the UE occupies the channel. Since TDM UEs can generate different self-deferment values, a UE with a larger deferment value will detect the occupancy from a UE with a smaller deferment value and avoid collision.
[0253] UE self-delay value on multiple OS
[0254] For NR-U, by using the flexible nature of PUSCH resource allocation, self-delay and multiplexing can be enhanced to better utilize resources; unlike LTE, NR already supports PUSCH transmission starting from any symbol of the time slot and PUSCH transmission for different durations (variable OS). By leveraging this, NR-U can allow NR-AUL PUSCH transmission to use different starting positions.
[0255] We propose in this paper to enable the gNB to configure the UE via RRC signaling with a subset S = {s 1 ,s 2 ,..s T} for NR-AUL PUSCH transmissions after channel access. If every possible symbol position within a slot is allowed, the gNB will bear a considerable burden of detecting UE transmissions on every symbol of the slot.
[0256] As an example, Fig.10 Figure 1 shows that UE1 and UE2 compete for channel access to the same resource. UE2 has a smaller self-delay and can therefore 1 = Acquires the channel at OS#0 and blocks UE1. It has a mini-slot NR-AUL PUSCH transmission length of two symbols in OS#1 and OS#2, and CP extension in OS#0. UE2 completes transmission on OS#2.
[0257] UE1 has s 2 = Fourth OS. It tries and obtains channel access on OS#4 for NR-AUL PUSCH transmission.
[0258] UE in time slot s i A random self-delay value is generated in s OS for obtaining channel access. The self-delay value is <= 1 OS and can be randomly selected by the UE from pre-configured values. If channel access fails, the UE uses another randomly generated self-delay value in s i+1 The UE continues this process until it gains channel access in that timeslot; otherwise, if it fails, it repeats the process for the next adjacent NR-AUL timeslot starting with i=1. i Code element s is performed on the part i+1 CP expansion. Fig.11 This process is shown.
[0259] PUSCH duration indication to gNB
[0260] Note that in AUL feLAA, PUSCH transmission starts only at OS#0 or OS#1. In NR-AUL PUSCH, if we allow PUSCH transmissions starting at different OS positions within a slot, then the following scenarios can be considered for the duration of PUSCH transmission. The length L OS (e.g., the duration of NR-AUL PUSCH transmission) can be configured by RRC or indicated to the UE by activating DCI. The UE can transmit NR-AUL PUSCH in the following ways.
[0261] · Transmission of NR-AUL PUSCH of length L
[0262] Even if the UE delays channel access to the resources, it still transmits a PUSCH of length L, which can span slot or mini-slot boundaries; this is like a sliding window for transmitting a PUSCH of length L, where the start time depends on channel availability. As Fig. 12A shown, the PUSCH symbols can be counted from the partial OS where channel access is obtained (the partial OS carries an extended CP). Here, UE1 is configured for full-slot PUSCH transmission but obtains channel access at s i = 4. The symbol lengths of PUSCH1 and PUSCH2 transmissions are 14 symbols and start at OS#4 of the slot and end at OS#3 of the next slot. On OS#4 of slot #n, the UE performs CP extension of OS#5 for PUSCH1 transmission.
[0263] Alternatively, as Fig. 12B shown, the PUSCH symbols can be counted from the OS where the UE obtains full access. UE1 transmits PUSCH1 from OS#5 in slot #n to OS#4 in slot #n+1.
[0264] · Transmission of variable-length NR-AUL PUSCH
[0265] We propose in this paper to also allow the UE to transmit PUSCH of P OSs with a shorter length (P < L) according to resource availability. P can be selected by the UE. P can be restricted to a set of values configured by the gNB to the UE via RRC signaling.
[0266] For example, due to delayed channel access, the first NR-AUL PUSCH transmission of the UE can be shorter than L. The UE aligns subsequent NR_AUL PUSCH transmissions to certain boundaries (such as slot or mini-slot boundaries). Fig. 12C Illustrated is where UE1 is at s i=4. It is configured for PUSCH transmissions of length L=14 (slot duration). But its first transmission PUSCH1 is shorter and goes from OS#4 to OS#13 of slot #n. In OS#4, the UE performs CP extension for OS#5. PUSCH2 and PUSCH3 transmissions are aligned with slot boundaries and occur in slots n+1 and n+2, respectively, of full length L.
[0267] If not enough NR-AUL resources are available, either because the UE's COT expires or because no NR-AUL resources are assigned, then the PUSCH transmission may be terminated in the last possible OS and may be shorter than L; if resources only allow less than L OS, then this allows the UE to fully utilize the channel access opportunities without wasting them. Fig.12D As seen in , the PUSCH3 transmission is short and ends at the end of slot #n+2 where the AUL resources end.
[0268] Alternatively, if there are not enough AUL resources to transmit a PUSCH of length L,
[0269] Then the UE may no longer transmit any NR-AUL PUSCH, such as Fig.12E as shown in .
[0270] For variable length PUSCH transmissions, the UE’s PUSCH transmission length MUST be implicitly derivable at the gNB or explicitly indicated to the gNB via the NR-A UL-UCI.
[0271] Implicitly derive the PUSCH length at the gNB
[0272] The gNB identifies the DMRS and is aware of the NR-AUL UE activity. If the DMRS position indicates the starting OS of the PUSCH transmission, then the gNB can calculate the number of OS in the PUSCH transmission from the position of the DMRS until the end of the slot or simulated slot or NR-AUL resource.
[0273] Alternatively, if the DMRS position is not an indicator of the start of a PUSCH transmission, the gNB may select a value from the set S of possible lengths for the transmission. L NR-AUL-UCI is detected blindly on the S (this is the assumption for blind detection). The NR-AUL-UCI position and mapping depends on the PUSCH resources, especially the starting position of the PUSCH and the number of resources used for the PUSCH (depending on the length of the PUSCH). L If it is restricted to a few values, the complexity of blind decoding is small.
[0274] Explicit indication of PUSCH length via NR-AUL-UCI
[0275] Give UE autonomy to transmit shorter PUSCH to align with slot / mini-slot boundaries or transmit full-length PUSCH or adjust the length according to COT or available NR-AUL resources. We propose in this paper to include timeDomainAllocation information about the PUSCH transmission length (expressed in either number of OFDM symbols or absolute time units) in the NR-AUL-UCI.
[0276] The PUSCH can be type A or type B as defined in NR; the position of the first DMRS of the PUSCH of type A can be on OS#2 or OS#3, while the position of the first DMRS of the PUSCH of type B is at the beginning of the PUSCH. The UE can be configured for type A or type B NR AUL PUSCH transmissions through RRC. Alternatively, it can be configured for type A and type B NR-AUL PUSCH transmissions, where each type is used under certain conditions, such as the starting codeword of the PUSCH transmission, the duration of the PUSCH transmission, etc. The UE can use one bit in the NR-AUL-UCI to indicate the type.
[0277] NR-AUL-UCI resources on PUSCH for variable length PUSCH
[0278] Currently in NR and LTE for UCI mapping on PUSCH, the UE calculates the resources for UCI based on the total number of PUSCH symbols. If this approach is used, then the NR-A UL-UCI will have different resources based on the length of PUSCH. The gNB has to blindly decode the possible UCI locations and resources (corresponding to the PUSCH length).
[0279] To limit the amount of NR-AUL-UCI decoding at the gNB, we also propose to use the same amount of resources for NR-AUL-UCI on PUSCH for each possible PUSCH length so that UCI can be detected regardless of the length of PUSCH and the gNB is not required to perform blind decoding.
[0280] We also propose in this paper to map NR-AUL-UCI for different PUSCH types / lengths to allow gNB to have minimal blind decoding. When the gNB detects DMRS to identify UE activity, the NR-AUL-UCI can be mapped relative to the position of the DMRS – for example, mapping can start on the symbol after the first DMRS OS so that the gNB can detect NR-AUL-UCI on both Type A and Type B transmissions in the same way.
[0281] Alternatively, we can support a limited set of NR-AUL-UCI mapping locations, for example, the starting symbol set relative to the first DMRS of PUSCH, because the different lengths and types of PUSCH transmissions (A / B) can ensure that there are enough resources for NR-AUL-UCI. The gNB blindly decodes these NR-AUL-UCIs based on where the DMRS is found.
[0282] The concept is Fig.13 , where 4OS, 7OS and full-slot PUSCH transmissions have the same mapping and number of UCI resources for PUSCH. If the DMRS indicates the start OS of PUSCH, then the gNB detects the DMRS and gets the start of PUSCH, from which it detects the NR-A UL-UCI resources.
[0283] The gNB decodes the UCI and if successful, it obtains the timeDomainAllocation. It then obtains the length of the PUSCH transmission and continues decoding the data.
[0284] The timeDomainAllocation field can include one or more of the following:
[0285] οPUSCH starting symbol position
[0286] ο Length of PUSCH
[0287] The modulation type used for NR-A UL-UCI can be configured to the UE by RRC, or the UE can use a fixed modulation type such as QPSK or BPSK or Similar to UCI transmission for ACK / NACK or CSI transmission on PUSCH, The value may be configured by RRC to the UE and used to calculate the resources for NR-A UL-UCI. The number of decoded modulation symbols per layer for HARQ-ACK transmission, denoted as Q′, may be determined as follows NR-AUL-UCI .
[0288]
[0289] in
[0290] -O NR-AUL-UCI is the number of NR-AUL-UCI bits;
[0291] -L NR-AUL-UCI is the number of CRC bits of HARQ-ACK;
[0292] -
[0293] -C UL-SCH is the number of code blocks of UL-SCH used for PUSCH transmission;
[0294] - If the DCI format scheduling the PUSCH transmission includes a CBGTI field indicating that the UE will not transmit the rth code block, then K r =0; otherwise, K r is the rth code block size of the UL-SCH of the PUSCH transmission;
[0295] - is the scheduled bandwidth for PUSCH transmission, expressed as a number of subcarriers;
[0296] - is the number of subcarriers in OFDM symbol l that carries PTRS in PUSCH transmission;
[0297] - is the number of resource elements in PUSCH transmission that can be used for UCI transmission in OFDM symbol 1
[0298] - is the total number of OFDM symbols configured for full-length PUSCH transmission for the UE, including all OFDM symbols used for DMRS;
[0299] - is the total number of OFDM symbols for the shortest PUSCH transmission configured for the UE, including all OFDM symbols used for DMRS; here, p≤f.
[0300] - For any OFDM symbol carrying DMRS for PUSCH, - For any OFDM symbol not carrying DMRS for PUSCH,
[0301] - α∈{0.5,0.65,0.8,1} is configured by the higher layer parameter uci-on-pusch-scaling;
[0302] -l 1 is the symbol index of the first OFDM symbol that does not carry DMRS for PUSCH after the first DMRS symbol(s) in PUSC.
[0303] Fig.14A and Fig. 14B The concept of NR-A UL-UCI on PUSCH is illustrated.
[0304] If PUSCH also carries other UCI such as ACK / NACK and CSI, then the NR-A UL-UCI can be mapped first in a frequency-first manner. ACK / NACK and CSI can be mapped to their corresponding positions currently defined in NR, but they do not cover the NR-A UL-UCI resources; therefore, they slide over the position of the NR-A UL-UCI.
[0305] Scrambling for NR-A UL-UCI
[0306] In NR and LTE, UCI is mapped to its resource on PUSCH and PUSCH is scrambled with a sequence initialized with either the cell ID or a UE-specific ID. However, if scrambled with a UE-specific ID, then the gNB has to decode the NR-AUL-UCI for each UE that may correspond to the detected DMRS sequence. On the other hand, using a cell ID-based scrambling sequence will enable the gNB to decode the NR-AUL-UCI UE-independently, but the data on PUSCH will also be scrambled with a cell ID-based sequence, which makes it less robust compared to a UE-specific sequence.
[0307] In this paper, we propose to handle NR-A UL-UCI scrambling in the following way to solve this problem.
[0308] Even if a UE-specific scrambling ID for PUSCH is configured for the UE, the UE uses only the cell ID or aul ID configured by the gNB. The same aul ID is configured for multiple UEs so that the NR-AUL-UCI of all these UEs will be scrambled using the same aul ID. The gNB decodes the NR-AUL-UCI for possible configured aul IDs; upon decoding, the UE-ID (e.g., C-RNTI) is obtained from the payload of the NR-AUL-UCI.
[0309] NR-AUL-UCI is scrambled only by the cell ID or aul ID. The rest of the resources on PUSCH are scrambled by a UE-specific ID. Once the gNB detects the UE ID, it knows the UE-specific ID to use for descrambling when processing the data.
[0310] Multiple NR-AUL grants for timing flexibility
[0311] As an alternative to configuring self-delay for a UE on multiple OSs, the gNB can configure multiple NR-AUL grants for the UE, where each grant has a different timing offset. This allows the UE to start transmission on a resource if the previous resource is not available due to LBT failure. The timing offset can be a slot offset, symbol offset, or mini-slot. The grant can be type 1 or type 2.
[0312] The concept is Fig.15A and Fig. 15B , there are multiple NR-AUL grants with different time offsets. Here, two NR-AUL grants are available to the UE, each with a different time offset within the time slot. The offset of grant #1 is 0OS, while the offset of grant #2 is 4OS. The UE performs LBT to gain access to the resources of grant #1. If available, the UE transmits PUSCH1, such as Fig.15A If LBT fails, the UE attempts to access grant #2. If LBT succeeds, the UE attempts to access grant #2. Fig. 15B As shown in , the UE transmits PUSCH1 on grant #2. Here, the PUSCH1 transmission is aligned at the time slot boundary. In general, it can also cross the time slot boundary, such as Fig. 12B as shown in .
[0313] The UE may generate a self-delay value to access the channel in the following manner.
[0314] Generate a single self-extending value for accessing any grant. The UE may randomly select the value from a possible list of random values provided to it by the gNB or predefined in the specification. The same value should be used for accessing Fig.15A and Fig. 15B License #1 or License #2.
[0315] Separate self-delay values are generated for access to each grant. They can be randomly generated from a list of random values predefined by the gNB configuration or specification. This has the advantage that if the UE loses access to one grant due to a large self-delay value, it still has a good chance of acquiring resources on another grant since the self-delay value for that access is generated independently.
[0316] Since time and frequency resources can be the same or similar between multiple grants, the gNB must be able to identify the grant used by the UE. We propose in this paper to use the DMRS of the NR-AUL PUSCH to identify the grant; therefore, each grant is configured by RRC to have a unique DMRS sequence initialization or a unique DMRS port.
[0317] The UE may access its NR-AUL grant resources in the following manner.
[0318] In each channel access (e.g., acquired COT), the UE can only use resources from a single grant. If the UE starts transmitting on grant #1, then it continues to use only the resources of grant #1 until it releases the channel. This simplifies the processing at the gNB that relies on DMRS assumptions to detect UE ID and resources.
[0319] UE can use resources from multiple grants within COT. Fig.16 This can be used especially during UE-COT sharing with the gNB as shown in . Here, the UE uses grant #1 before COT sharing and grant #2 after the gNB's symbol. Grant #2 is configured to start on OS #3. Here, the PUSCH transmission crosses the slot boundary.
[0320] We also propose in this paper to indicate the autonomously selected NR-AUL grant in the NR-AUL UCI. This increases the robustness of detecting autonomous UEs. For example, the RNTI used to scramble the UCI can be a function of the grant ID, or the grant ID can be carried in the UCI payload.
[0321] PUSCH repetition
[0322] We propose in this paper that autonomous transmissions should support repetition of NR-AUL transmissions. This is particularly beneficial for mMTC and URLLC as it allows multiple transmissions to be made in time for improved reliability and reduced power consumption (since repeated bursts can be done in one go). The CG in NR supports a bunch of consecutive repetitions of the HARQ process. In feLAA AUL, the AulTransmissionTimer is triggered on the first transmission of a HARQ process; if the UE does not receive feedback about the HARQ process from the gNB, the HARQ process can be repeated.
[0323] AUL-UCI for Repeated
[0324] In this paper, we propose to support the autonomous repetition of TB in NR-AUL. We define time period t bundle The retransmission of the HARQ process within a retransmission bundle is called a repetition bundle. The gNB configures the UE to retransmit the HARQ process within a retransmission bundle through RRC signaling. bundle The maximum number of repetitions repK can also be configured to the UE through RRC signaling. The UE can use the duration t repeat =min(t bundle ,COT) repeats the transmission up to repK times.
[0325] Since asynchronous HARQ may be supported for NR-AUL, the repetitions do not have to be consecutive.
[0326] For example, if the UE has two HARQ processes to transmit and has repK=4, it can either Fig.17A Repeated transmissions are performed continuously as shown, or as Fig. 17B The HARQ processes are shown to be alternating so that it can transmit both processes in the MCOT without waiting for the repetition bundle of one process to complete; therefore, for each HARQ process, the UE can transmit less than repK times.
[0327] The NR-A UL-UCI on the first PUSCH transmission in the COT may indicate one or more of the following to the gNB:
[0328] The number of HARQ processes to be transmitted
[0329] Type of repetition (continuous or alternating between processes or other non-periodic patterns)
[0330] The UE may autonomously select certain transmission parameters common to all NR-AUL transmissions in the COT, such as, for example: MCS; RV; HARQ process number; and UE-ID.
[0331] We propose in this paper to provide the UE with the ability to indicate common parameters only on certain transmissions and not on others, in order to minimize the NR-A UL-UCI overhead.
[0332] For example, the UE may only Fig.18A The MCS is indicated in the first NR-AUL PUSCH transmission of the COT shown. The NR-AUL-UCI on other PUSCH transmissions cannot carry the field for MCS.
[0333] In another example, Fig.18B As shown in , the UE can transmit repetitions in a bundle and indicate the MCS and HARQ process ID (and repeated RV) in the first PUSCH transmission of the HARQ process in that COT. The NR-A UL-UCI on other PUSCH transmissions in the bundle cannot carry fields for MCS and HARQ process ID.
[0334] exist Fig. 18C In , we have an example where the repetitions of the HARQ process in a bundle do not carry the NR-A UL-UCI. The first transmission of that HARQ process in the bundle carries information about the repeated RV.
[0335] NRAulTransmissionTimer
[0336] The UE may autonomously transmit repetitions within the COT, so the repetitions of the bundle may not occur continuously, e.g. Fig. 17B as shown in the example.
[0337] NRAulTransmissionTimer may be defined for each HARQ process configured for NR-AUL transmission. NRAulTransmissionTimer may be set on the last transmission of a HARQ process in a bundle. NRAulTransmissionTimer decrements over time; when it expires, the UE may retransmit the HARQ process on NR-AUL resources. In practice, the UE may set NRAulTransmissionTimer to the RRC configured value each time a HARQ process is transmitted within the COT; effectively, this will set the timer on the last transmission of the HARQ process. This concept is discussed in Fig.19 Shown in.
[0338] Note that this is different from configureGrantTimer in NR and AulTransmissionTimer in feLAA, where the first PUSCH transmission of a HARQ process causes the timer to start.
[0339] Interleaving in HARQ Repetition
[0340] PUSCH transmissions for NR-U may use some form of block interleaved FDMA (BI-FDMA) similar to that used in eLAA. We propose in this paper that the repetition of the HARQ process may use different interleaving to exploit frequency diversity, e.g. Fig. 20 as shown in .
[0341] The interleaving for the HARQ process and its repetitions may be configured either by RRC (e.g., in a type 1 NR-A UL grant) or by activation DCI (e.g., in a type 2 NR-A UL grant).
[0342] Alternatively, the interleaving for the first transmission in a bundle may be configured either by RRC (e.g., in a type 1 NR-AUL grant) or by activation DCI (e.g., in a type 2 NR-AUL grant), and the interleaving due to repetition may be derived as an offset from the interleaving of the first transmission in the bundle. The offset is a function of one of the following multiple factors.
[0343] The kth repetition in the bundle
[0344] HARQ process ID
[0345] RV of HARQ process
[0346] UE-ID, such as NR-AUL-RNTI or C-RNTI
[0347] Timeslot number in the frame
[0348] If multiple UEs are interleaved, collisions can be avoided by assigning the same offset to the UEs. Fig.21 Here, UE1 and UE2 have the same offset in each repetition, so they will not collide.
[0349] In practice, if there is a lot of traffic, then the gNB can allocate resources to multiple UEs and avoid collisions altogether. In this case, each UE can have an independently configured offset for its repetitions; thus, some repetitions may not collide. Fig. 22 Shown in.
[0350] UE-COT sharing with gNB
[0351] In AUL feLAA, the UE can share the COT with the eNB and DL transmit up to two OS for control signaling to support UL-DL switching.
[0352] We propose in this paper to enhance this COT sharing mechanism for NR-AUL. We propose in this paper that NR-AUL supports at least UL-DL-UL switching and potentially multiple UL-DL switching in a shared COT so that a UE can regain channel access within its COT after a channel use by a gNB. Fig.23 In the example, UE1 transmits PUSCH1 and PUSCH2, and then it shares the channel with the gNB. The last symbol of PUSCH2 can be used to switch to DL. The gNB uses D OSs for DL transmissions to at least the COT shared UEs, especially DL control information such as NR-AUL-DFI carrying ACK / NACK for NR-AUL and scheduling grants.
[0353] Afterwards, the eNB returns the channel to UE1, and UE1 can transmit UL within its remaining COT - this transmission can be NR-AUL or S-UL transmission.
[0354] The OS following the DL may provide either a 16 μs switching time to return to UL transmission, or a 25 μs time for the UE to perform LBT and regain access to the channels within its original COT.
[0355] Fig.23 Another example is provided where the UE’s PUSCH transmission length is variable due to COT sharing, as seen in the transmission of PUSCH 3. If the PUSCH length can be indicated via the NR-A UL-UCI, then more flexibility can be provided when pre-configuring the CORESET.
[0356] Triggered S-UL grant in shared COT
[0357] In eLAA, since it takes 4ms to process the UL grant, triggered grant is introduced. Here, the eNB gives the UL grant to the UE with flexible timing resources. The UE prepares the TB after receiving the grant. Subsequently, the eNB initiates the trigger via C-PDCCH (Common-PDCCH) based on the channel availability. On receiving the trigger, the UE transmits the PUSCH with minimal latency. The timing between the grant and the trigger is flexible.
[0358] In NR-U, we propose in this paper to enable DCI triggering of gNB during shared COT so that UE1 can transmit S-UL on NR-AUL resources within its MCOT after gNB returns the channel to UE1, as shown in Fig.24 As shown in . UL grants can be given through DCI. Triggers can occur through GC-PDCCH. S-UL grants can also be provided to UEs other than the UEs sharing its COT.
[0359] This mechanism can be used to trigger multiple S-UL grants within the remaining MCOT. However, the gNB must know the duration of the UE's remaining COT in order to schedule timing resources within the remaining COT. Therefore, we propose in this paper to introduce an indication of the remaining COT through NR-A UL-UCI in one of the following ways.
[0360] The field "remainingCOT" is transmitted in the NR-A UL-UCI to indicate the offset of the symbol or slot in which the UE has the COT. The UE may be required to transmit a valid value of remainingCOT only in the NR-A UL-UCI that triggers COT sharing.
[0361] A CRC mask as a function of the offset is used to mask the CRC of the NR-A UL-UCI. The gNB decodes the NR-A UL-UCI and selects a CRC mask that enables a successful CRC check; this CRC mask provides the remaining COT information to the gNB.
[0362] RTS-CTS handshake shared via COT
[0363] In this paper, we propose a mode to support UE and gNB handshake in NR-U to ensure that the channel is clear at both ends and not obstructed by hidden nodes. Fig.25 As shown in , the UE can transmit NR-A UL-UCI with only UCI on PUSCH in a few OS and hand over the channel to the gNB. If the gNB receives the UE's transmission, it transmits a CTS signal, which can be in one of the following forms.
[0364] GC-PDCCH. GC-PDCCH based acknowledgements may be transmitted to one or more UEs on a CORESET in a shared COT.
[0365] UE-specific RS, which is configured similarly to CSI-RS
[0366] NR-AUL-DFI scrambled with NR-AUL-RNTI. NR-AUL-DFI may be set to a special value to indicate to the UE that NR-AUL-UCI has been decoded. Thus, although there is no specific HARQ process, the UCI is still confirmed.
[0367] When the UE receives it, the handshake is complete and the UE takes over the COT and starts data transmission on the NR-AUL resources in the remaining COT. In general, multiple UL and DL switching can be supported in NR-AUL, although this is at the expense of providing switching gaps.
[0368] DL CORESET in Shared COT
[0369] In AUL feLAA, the DL symbols of the shared COT appear at the beginning of the partial end subframe after the end of the AUL subframe. PDCCH is always configured to appear at the start OS of the LTE subframe, and all UEs monitor DCI in each subframe. Therefore, UEs sharing the COT can monitor the shared DL OS for AUL-DFI or other control signaling.
[0370] But in NR, UE is configured with CORESET and associated search space with certain monitoring periodicity. Moreover, due to the flexibility of the start and stop position of PUSCH transmission, the opportunity for DL OS can appear anywhere in the time slot, but the UE may not be configured for the CORESET and search space set in those symbols. In order to ensure that the CORESET can be provided for UEs sharing the COT, we propose the following solution.
[0371] Flexible time resources for AUL search space set
[0372] As a solution, we propose to configure an “AUL search space set” in NR-U to enable reception of DL control signaling during UE COT sharing. The UE monitors an AUL search space set with one or more of the following characteristics.
[0373] Unlike the currently configured search space set in NR, it is not periodic; the UE monitors it only if it shares its COT with the gNB, otherwise it does not monitor it.
[0374] It has a flexible offset within the slot; it occurs in the OS after the LBT gap after the last symbol of the PUSCH transmission. Therefore, its time resources can be flexibly allocated after a mini-slot or a slot. Channel access and COT sharing require dynamic triggering of the time resources for the AUL search space set.
[0375] Can only appear on AUL symbols with flexible transmission direction; for example, "X" in SFI
[0376] It is associated with a CORESET that provides frequency resources, QCL information, and mapping type, similar to the CORESET of a periodic search space set.
[0377] The concept is Fig.26A and Fig.26B , where CORESET resources are provided immediately after COT sharing.
[0378] If the UE has been configured with a regular (non-flexible) search space set starting from the start position of the DL OS of the shared COT, then it is assumed that there is no need to monitor the AUL search space set in that COT. Instead, the UE monitors the non-AUL search space set to obtain its DL control information.
[0379] The duration of the CORESET associated with this AUL search space (via controlResourceSetId) determines the duration of the DL region in the shared COT.
[0380] The UE may be configured with multiple AUL search space sets that may be associated with different CORESETs; for example, a CORESET may have different durations (1 or 2 or 3 OSs). Depending on the OS at which the DL part starts, a CORESET with a certain duration may be used. Therefore, the starting symbol of the DL may be associated with the CORESET ID through RRC configuration.
[0381] Use the configured CORESET
[0382] The UE may have NR-AUL resources assigned with flexible scheduling “X” in the OS, but may also assign the CORESET to be configured or scheduled as “X” through OS monitoring. If the UE shares the COT with the gNB, then it terminates its NR-AUL-PUSCH before the CORESET so that the gNB can perform 25μs LBT and transmit DL control signaling on the CORESET.
[0383] Fig. 27 An example is shown where UEs share the COT so that the gNB can transmit on a configured CORESET that is periodically monitored by the UE.
[0384] The UE may indicate the CORESET on the shared COT in one of the following ways.
[0385] The UE may signal on the NR-A UL-UCI of the PUSCH transmission with 1 bit in slot #n to indicate the (n+k)th slot in which the CORESET occurs, e.g. Fig.28 As shown in ; k is configured to the UE by RRC.
[0386] If only one CORESET / search space is configured for monitoring on this timeslot, then the gNB does not ambiguously identify it, such as its duration and time position. However, if multiple CORESETs can occur in a timeslot, or multiple search space sets can occur within a timeslot with different offsets or periodicities, then the gNB may not know where COT sharing starts. To address this, the UE can indicate one of the following.
[0387] ο Length of the last PUSCH transmission before switching to DL by NR-A UL-UCI.
[0388] o ID of the CORESET, such as controlResourceSetId, which is configured by RRC for each CORESET configured to the UE. The ID indicates the number of CORESET symbols, frequency domain resources, DMRS sequence, QCL relative to RS, etc. Since a CORESET can be associated with multiple search space sets, the gNB can use the timing resource of the first occurrence of (one or more) search spaces in a specified time slot.
[0389] o An ID of the search space, such as searchSpaceId, which is configured by RRC to the UE. This indication is sent via the NR-A UL-UCI. Upon receiving this information, the gNB knows the timing resources, e.g., periodicity and slot offset for PDCCH resources. Currently in NR, RRC also configures an association between searchSpaceId and controlResourceSetId. Thus, the knowledge of searchSpaceId provides the gNB with all the information about the resources referenced for sharing in COT. This concept is in Fig.29 Shown in.
[0390] COT sharing with gNB in FDM scenarios
[0391] For low latency applications and mMTC applications, user FDM can provide low latency and save power. The gNB can provide different frequency interleaving to different UEs so that they can transmit on the same NR-AUL resources. To ensure that one UE does not block another UE, the gNB can configure all UEs to use a common self-delay value when accessing resources. The self-delay value is configured for the UE via RRC signaling or activation DCI.
[0392] In the FDM scenario, it is also expected to share the COT with the gNB, but the problem is that the accessing UEs can have different COTs, different COT expiration times and cannot share the same resources synchronously with the gNB.
[0393] We propose in this paper to support periodic COT sharing with the gNB for the duration of the NR-AUL resources. The gNB configures the period P and the number of OSs for the UE via RRC. The gNB can typically configure a CORESET and search space for a set of UEs, which they must monitor even during their own COT. Therefore, the UE terminates its NR-AUL PUSCH transmission 1OS before the resources indicated by this CORESET and search space, and allows the gNB to gain access via 25μs LBT, as shown in Figure 2. Fig.25 as shown in .
[0394] When the gNB obtains the shared COT, it can transmit a new LBT threshold to the FDM UE to indicate that the channel is occupied by the FDM UE and other UEs (with FDM interleaving) can also transmit on its resources. This will enable other NR-AUL UEs to FDM their NR-AUL resources. In the absence of a threshold, the UE will be blocked by the UE that has obtained the COT. The threshold can be transmitted via GC-PDCCH.
[0395] refer to Fig.25 , if FDM is used to multiplex UEs for RTS signaling, then the gNB can receive RTS from multiple UEs and respond to all UEs during the shared COT.
[0396] Autonomous frequency resource selection in NR-AUL
[0397] Previous solutions have focused on enabling UEs to autonomously select time resources and HARQ parameters (such as ID and RV) for PUSCH transmission. While autonomous selection of time resources can improve efficiency and flexibility, higher resource efficiency and latency reduction can also be achieved by allowing autonomous selection of frequency resources. If multiple frequency resources are available to the UE, the likelihood of obtaining channel access increases.
[0398] Since NR is designed to work with a large spectrum, we propose in this paper that NR-U UE is configured with multiple frequency resources and is allowed to autonomously transmit PUSCH on the frequency resources where the UE LBT succeeds and obtains channel access.
[0399] For example, Fig.31A and Fig.31B As shown in , in the 80 MHz broadband spectrum, each 20 MHz sub-band can provide one frequency resource to the UE. The UE is configured with frequency resources R1, R2, R3, R4 and R5. The UE can autonomously select one of them for NR-AUL transmission.
[0400] The UE can select a 20MHz subband for its LBT successful transmission. Fig.31A In the present invention, when the UE obtains channel access to the corresponding subband, the UE selects the NR-AUL frequency resource R2 for transmission.
[0401] Alternatively, if LBT is successful for all those subbands, the UE may select frequency resources that may span multiple adjacent subbands; this allows the UE to utilize a larger amount of frequency resources, thereby reducing latency and increasing capacity in the network. Fig.31B In the embodiment, when the UE obtains channel access to the three corresponding subbands, the UE selects the NR-AUL frequency resource R5 for transmission.
[0402] NR-AUL frequency resources on each BWP
[0403] For NR-U, we propose in this paper to configure NR-AUL frequency resources for the UE on more than one BWP; the UE has a list of candidate BWPs for AUL transmission. The UE performs LBT across each candidate BWP and autonomously selects the BWP with successful LBT.
[0404] Note that in NR Release 15, a UE can be configured with up to four BWPs, but only one active BWP can be used to receive and transmit PDSCH and PUSCH at a time. The gNB schedules BWP switching via PDCCH. In addition, the UE runs a BWPInactivityTimer that counts the period of inactivity on the BWP; the UE switches to the default BWP when its BWPInactivtyTimer expires. There is no concept of autonomous selection of BWP in NR Release 15.
[0405] Fig.32A and Fig.32B An example of BWP-based frequency resources is shown. The UE is configured with BWP1, BWP2, BWP3, BWP4, and BWP5. Each BWP has NR-AUL resources. Fig.32AIn the process, the UE obtains channel access to BWP2 and uses the NR-AUL resources in BWP2 for NR-AUL PUSCH transmission.
[0406] exist Fig.32B In the present embodiment, the UE obtains channel access to BWP5 (in which BWP1, BWP2 and BWP3 are nested) and uses the NR-AUL resources in BWP5 for NR-AUL PUSCH transmission.
[0407] Autonomous selection in Type 1 NR-AUL transmission
[0408] If the NR-AUL resources in the BWP with channel access are type 1, then since the UE is configured with an AUL grant by RRC, it can start NR-AUL PUSCH transmission on its resources after channel access. The gNB recognizes that the UE has autonomously selected the resources after receiving its DMRS, or obtains the identity of the UE through the NR-AUL-UCI. Fig.33 An example of configuring type 1 resources in BWP1, BWP2, and BWP3 for a UE is shown. The UE selects BWP2, BWP1, and BWP3 in different situations based on channel availability after LBT.
[0409] In unpaired spectrum, since the UL and DL BWP are the same, the gNB has to switch the DL-BWP to the UL-BWP selected autonomously by the UE so that COT sharing can occur on that spectrum, e.g., DL-BWP = UL-BWP.
[0410] As an example, the procedures for BWP access and handover are given below for unpaired spectrum.
[0411] 1. UE obtains channel access to BWP1.
[0412] 2. The UE transmits NR-AUL PUSCH. The UE sets the timer BWPInactivityTimer when transmitting NR-AUL PUSCH on BWP1 in that COT.
[0413] 3. The gNB detects the UE’s DMRS or UE ID on the NR-A UL-UCI and switches to BWP1 on DL.
[0414] 4. The gNB transmits NR-AUL-DFI to the UE on BWP1; this may happen during COT sharing on BWP1.
[0415] 5. The gNB can schedule DL and UL transmissions for the UE on BWP1.
[0416] 6. After the UE's COT expires, if the UE has NR-AUL data to transmit, then it can seek channel access to one of the BWPs in the candidate BWP list. For example, the UE obtains channel access to BWP2. Otherwise, the UE can try channel access on BWP1 again.
[0417] 7.UE and gNB repeat steps 2-6 for BWP2.
[0418] The timeline of events for this process is in Fig.34 . The UE initially operates in BWP1. It cannot obtain channel access to the NR-AUL resources in BWP1. It autonomously obtains channel access to BWP2 and transmits NR-AULPUSCH and sets BWPInactivityTimer when it obtains NR-AUL grant. The gNB identifies the UE and switches the DL BWP; it transmits NR-AUL-DFI in the COT shared resources of the UE on BWP2.
[0419] Another example of the procedure for BWP access and switching is given below for unpaired spectrum. Here, the UE does not perform COT sharing with the gNB. It transmits only NR-AUL and releases the channel. In this case, the gNB may not switch the DL-BWP to BWP2. And, the UE returns to BWP1 after completing the NR-AUL transmission. It receives ACK / NACK feedback for NR / AUL transmission on BWP1.
[0420] 1. The UE's UL and DL active BWP is BWP1.
[0421] 2.UE needs to transmit NR-AUL PUSCH, but cannot access BWP1.
[0422] 3. The UE attempts autonomous BWP selection and obtains channel access to BWP2.
[0423] 4. The UE switches to the BWP and transmits NR-AUL PUSCH in its COT.
[0424] 5. After NR-AUL transmission on BWP2, the UE switches back to BWP1 and monitors UL and DL on BWP1
[0425] 6. The gNB transmits ACK / NACK feedback to the UE on BWP1 for the NR-AUL transmission occurring on BWP2.
[0426] 7. The timeline of events for the process is in Fig.35 Shown in.
[0427] In paired spectrum, when the UE autonomously switches to a different UL-BWP, the DL-BWP does not change. However, if the DL and UL BWPs are configured in pairs, for example, if the UL BWP switches, the DL BWP switches, then the operation is similar to that in unpaired spectrum.
[0428] Autonomous selection in Type 2 NR-AUL transmission
[0429] If the NR-AUL resource is type 2, then the UE can transmit only if the resource is activated to the UE via an activation DCI. If the UE can only operate one active BWP at a time, then the gNB is not aware that the UE autonomously owns a specific BWP. Therefore, the gNB cannot activate the resources to the UE. In addition, the UE must confirm the activation DCI via a MAC CE. This introduces huge latency and may not be done in the COT of the device. In addition, if this process has to be performed every time the UE autonomously selects a BWP, the signaling overhead will be high.
[0430] This problem can be solved by allowing the UE to be activated on multiple BWPs. The UE maintains the MAC configuration of the candidate BWPs for which it has received the activation DCI. The UE then autonomously selects one of the activated BWPs for which its LBT was successful and performs NR-AUL transmission. The procedures for BWP access and switching are similar to those for Type 1 for unpaired spectrum.
[0431] The UE may receive multiple Format 1_1 DCIs for activating resources on multiple BWPs. Alternatively, the gNB may receive multiple Format 1_1 DCIs for activating resources on multiple BWPs. i One activation DCI transmitted to the UE can activate NR-AUL resources on multiple BWPs.
[0432] Fig.36 An example of configuring Type 2 resources in BWP1, BWP2, and BWP3 for a UE is shown. NR-AUL resources for BWP2 are initially activated, while resources on BWP1 and BWP3 are not activated; in this case, the UE can transmit only on resources of BWP2 after gaining channel access. Resources on BWP1 and BWP2 are subsequently activated; the UE performs LBT across candidate BWPs with activated resources and selects a BWP with channel access for NR-AUL transmission.
[0433] Multiple NR-AUL frequency resources within a BWP
[0434] In some scenarios, a single BWP can be configured with multiple frequency resources, such as Fig.37A, where we see NR-AUL configured frequency resources R1 and R2. Here, when the UE gains access to the BWP, it can use all associated NR-AUL grants (configured for type 1 or activated for type 2) within its COT. Fig.38 , where the UE is configured with NR-AUL resources R1 and R2 each with different periodicity and PUSCH resource duration. When the UE gains channel access, it will transmit on the R1 and R2 resources in its COT.
[0435] exist Fig.37B In this example, the BWP may have a wide bandwidth and LBT may be performed across subbands within the BWP. One or more subbands in a BWP may contain NR-AUL resources. In this example, the UE is configured with resources R1 to R5, where R5 consists of multiple subbands in which the resources of R3 and R4 are nested. The UE may use NR-AUL grants in subbands for which it has successful LBT. If multiple NR-AUL Type 2 grants are activated, the UE may autonomously select them when operating on a single active BWP without having to operate on multiple active BWPs simultaneously.
[0436] The following example shows that you can apply Fig.37A The configuration situation in .
[0437] NR-AUL frequency resources may be associated with a minimum acceptable logical channel priority; NR-AUL grants may be used only if the priority of the content of the PUSCH exceeds the minimum acceptable priority. Different NR-AUL resources may be configured for different priority thresholds. For high priority cases, the periodicity or density of AUL resources in time may be greater.
[0438] One NR-AUL resource may offer all interlaces to a UE, allowing it to do TDM in the AUL resource, while other frequency resources may offer only some interlaces to a UE, allowing it to operate in FDM with other UEs; each resource may be suitable for different use cases – the TDM case with all interlaces may support eMBB packets, while the FDM case with one interlace may be suitable for mMTC packets.
[0439] For each frequency resource, the number of symbols used for PUSCH transmission may be different; a frequency resource with more frequent AUL resources and fewer PUSCH symbols may be more suitable for mMTC or URLLC than a frequency resource with less frequent PUSCH transmission but a larger number of symbols.
[0440] Criteria for frequency resource selection
[0441] A UE may be able to transmit NR-A UL on only one subband, but if its LBT is successful on multiple subbands, it may have multiple frequency resources to choose from. It may select the following resources based on one or more of the following criteria.
[0442] The frequency resource where the UE perceives the highest throughput – this can be because of available bandwidth or channel conditions allowing a favorable MCS or both
[0443] Frequency resources, providing transmission opportunities with minimal delay
[0444] • The frequency resource with the largest number of AUL time resources.
[0445] Frequency resources with minimum contention window size
[0446] Random frequency resources to support coexistence and fairness.
[0447] The gNB can configure the criteria for selecting frequency resources for the UE. For example, the gNB can configure the IDs of frequency resources in order from high to low priority. If the UE accesses multiple subbands or BWPs simultaneously, it can select the resource with the lowest index in the priority list.
[0448] The criteria can be based on the use case, for example, a URLLC UE may prefer criteria that improves reliability and reduces latency, while an eMBB UE may choose criteria for improving throughput. An mMTC UE may use a criterion that minimizes handover BWP to save power.
[0449] Frequency resource switching
[0450] When the UE's COT expires on R1, it may not immediately switch to another subband or BWP to resume NR-AUL transmission; it may be scheduled for DL or UL on R1. It may also receive ACK / NACK from the gNB for the previous NR-AUL transmission made on R1.
[0451] Therefore, we propose a UE maintenance timer aulResourceSwitchTimer in this paper, which is set under the following conditions:
[0452] UE receives DL grant on R1
[0453] UE receives UL grant on R1
[0454] UE transmits S-UL PUSCH on R1
[0455] UE receives NR-AUL-DFI on R1 indicating ACK / NACK of previous NR-AUL or S-UL transmission
[0456] The timer keeps decrementing and the UE stays on R1 until the following happens.
[0457] aulResourceSwitchTimer expires. Even if there is remaining COT on R1, UE will start autonomous selection of BWP.
[0458] aulResourceSwitchTimer expires. The UE starts autonomous selection of BWP after completing the remaining COT on R1.
[0459] After expiration, the UE performs LBT to identify new NR-AUL resources. If channel access is obtained, it can switch to R2.
[0460] Fig.39A The figure shows an example of autonomous selection of new frequency resources when the aulResourceSwitchTimer expires for LBT started for new resources after the aulResourceSwitchTimer expires. Fig.39B An example is illustrated where LBT for new resources starts after UE1's COT expires on R1.
[0461] Frequency resource identification at gNB
[0462] If the frequency resources used for autonomous selection overlap, then the gNB may not be able to identify the frequency resource on which the UE autonomously transmits. This can happen if nested BWPs or multiple resources within a BWP are configured for the UE, and the frequency resources may conflict. Currently, for CG in NR, the DMRS of the PUSCH is used to identify the UE; the DMRS is specific to the UE RRC configuration but is shared between BWPs – such a design causes ambiguity in identifying the frequency resource for the UE’s autonomous selection.
[0463] Therefore, a mechanism is required at the gNB to identify the autonomously selected frequency resources. We propose the following method to enable frequency resource identification.
[0464] Frequency resource identification based on parameters
[0465] If each BWP contains only one AUL frequency resource, then the frequency resource can be identified by the BWP ID BWP-Id. If a BWP contains multiple AUL frequency resources, then each frequency resource needs to be identified by the frequency resource ID aul-frequency-resource-id within that BWP. Therefore, we propose in this article that for NR-AUL Type 1, when multiple frequency resources are supported, the RRC configuration for the frequency resource should include aul-frequency-resource-id.
[0466] This parameter can be transmitted from the gNB on PDCCH to activate specific AUL frequency resources in NR-AUL Type 2.
[0467] We propose in this paper to enable the UE to transmit this ID via the NR-AUL-UCI so that the gNB can identify the frequency resource selected autonomously by the UE. The gNB starts by trying to decode possible hypotheses, e.g., the NR-AUL-UCI for possible frequency resources when it detects DMRS. It can only successfully decode one hypothesis; it identifies the frequency resource from the ID in the NR-AUL-UCI.
[0468] We also propose in this paper that the UE can scramble the NR-AUL-UCI with a frequency resource-specific RNTI. The RNTI can be configured to the UE by RRC in a frequency resource-specific manner, or can be implicitly derived by the UE from the aul-frequency-resource-id or BWP-Id. This frequency resource-specific scrambling randomizes the co-channel interference on the AUL resources.
[0469] DMRS Enhancement
[0470] The DMRS sequence for the CG in NR can be enhanced for NR-AUL by introducing a frequency resource specific configuration. For example, the initialization can be a function of the aul-frequency-resource-id. This ensures that the detection of the DMRS also enables the detection of the autonomous frequency resources and overcomes the ambiguity problem when the frequency resources are nested or partially overlapped.
[0471] Switching between multiple NR-AUL resources
[0472] Retransmission on different frequency resources
[0473] Similar to AUL feLAA, when an NR-AUL HARQ process is erroneously received at the gNB, the NR UE may receive a grant for scheduling of retransmission of that HARQ process, in which case it retransmits on the scheduled resources. Alternatively, the UE may receive a NACK as HARQ feedback for an AUL transmission via AUL-DFI, in which case the UE may retransmit autonomously.
[0474] Similar to aul-retransmissionTimer in AUL feLAA, nr-aul-retransmissionTimer can be configured for each HARQ process transmitted on NR-AUL resources. nr-aul-retransmissionTimer is set at the initial transmission of the HARQ process and decrements thereafter. If the UE does not receive ACK / NACK feedback for this HARQ process from the gNB, then it can try to retransmit the HARQ process on AUL resources if nr-aul-retransmissionTimer has expired.
[0475] We propose in this paper that the UE can autonomously select frequency resources for retransmission to perform transmissions. It can initially transmit on one type of NR-AUL resource (type 1 or type 2), but after the nr-aul-retransmissionTimer expires, send retransmissions on the same or different type of NR-AUL resources. The UE can autonomously select new resources, or the gNB can switch the UE to other resources by activating / deactivating or switching BWP.
[0476] Fig.40 An example of retransmission after expiration of nr-aul-retransmissionTimer for HARQ ID #0 is shown. The UE made the first transmission on R1 but did not get channel access on R1 for the retransmission. However, it gets channel access on R2 and sends the retransmission on that frequency resource.
[0477] Retransmission of S-UL HARQ process
[0478] It is possible that resources R1 and R2 may have different configurations of HARQ IDs that may be supported in NR-AUL. For example, R1 may support HARQ ID#0,1 for NR-AUL, while R2 may support HARQ ID#0,1,2,3. In this case, if the UE performs an S-UL transmission for HARQ ID#2 on R1 and subsequently gains access to R2, we propose in this paper that the UE may retransmit HARQ ID#2 on the NR-AUL resources on R2. This is because the gNB must identify the new resources autonomously selected by the UE before transmitting an ACK / NACK for HARQ ID#2 or rescheduling HARQ ID#2 as an S-UL grant. Instead, we allow retransmissions on the NR-AUL resources of R2, and thus the latency in identifying new resources or BWPs may be reduced. This concept is discussed in detail in the next section. Fig.41A Shown in.
[0479] Fig.41B An example of retransmission of HARQ ID#2 due to switching in the BWP is shown.
[0480] Enhancements to configured licensing
[0481] For synchronous HARQ transmissions in configured grants, such as in Release 15, the gNB identifies the UE from the DMRS and the HARQ ID and RV from the timing of the PUSCH transmission. In Release 15, CG resources are assigned for HARQ processes with a periodicity P and a repetition factor K. Below, we consider enhancements to configured grants to enable low-latency transmissions and efficient UE multiplexing to achieve good capacity in the cell. This solution can be applied to either synchronous or asynchronous HARQ transmissions.
[0482] Low latency transmission and repetition
[0483] For eURLLC, eV2X and NR-U, features such as back-to-back transmission of PUSCH based on mini-slots and multiple repetitions in a slot that are not supported in Release 15 are expected.
[0484] In this paper we propose some configurations for CG to enhance mini-slot based transmission. We use the term RP i Represents the repetition of the HARQ process within the bundle. The repetitions can have the same RV or different RVs. The RV for the repetitions can be configured to the UE through RRC. For example, for repetition K=4, i=0,1,2,3, and the following configurations of RVs can be used: RP={0,2,3,1}; RP={0,3,0,3}; RP={0,0,0,0}.
[0485] Fig.42A-D shows examples of various back-to-back PUSCH transmissions in a mini-slot. Fig.42A 2OS mini-slots are shown. Fig.42B 4OS mini-slots are shown. Fig.42C and 42D A mix of 7OS and 4OS mini-slots is shown. Fig.42A In -D, "ID" refers to the HARQ ID of the transmission.
[0486] The gNB configures a Type 1 or Type 2 grant for the UE with one or more of the following characteristics:
[0487] Mini-slots can be repeated back-to-back in a time slot. Fig.42A -D. Mini-slot transmissions provide low latency because in some cases the gNB may be able to decode the transmission from the first repetition RP0.
[0488] • Multiple HARQ processes can be repeated within a time slot. Fig.42A An example is shown in which HARQ IDs 0 and 1 are repeated in a time slot. Fig.42B Another example is shown for three 4OS mini-slots within a slot, each with a 1OS CORESET followed by a CG.
[0489] The repetition of the HARQ process can be continued to the next time slot. Fig.42A An example is shown in which the repetition of HARQ ID 1 is over two time slots.
[0490] • HARQ process repetitions may have different OS allocations. Fig.42C and Fig.42D Examples of HARQ processes transmitting on 4OS and 7OS mini-slots are shown. These configurations allow the first PUSCH to be decoded with low latency (compared to transmissions occupying the slot). Only if the first transmission fails to decode, the repetitions must be chase combined. Moreover, the variable allocation allows the transmission to be contained within the slot, which is preferred over transmissions extending to other slots, as extending to other slots will increase latency, especially if the next slot has a CORESET / DL symbol at the beginning of the slot. Here, HARQ processes transmitting with different OS will use the same MCS, but will be rate matched appropriately based on the number of available OS for transmission.
[0491] N HARQ processes can be transmitted before the repetition starts, for example, the HARQ IDs are interleaved in time before the repetition. This provides some time for the gNB to decode the HARQ process and provide feedback to the UE before the repetition. If the UE receives an Ack for the HARQ ID, then the UE does not need to transmit the next repetition, saving resources and power.
[0492] · Fig.43A and Fig.43B Some examples are shown where mini-slots are interleaved for several HARQ IDs and repeated after interleaving.
[0493] Depending on the slot format, the mini-slots in a grant can have different durations. Fig.43C As shown in , HARQ ID 0 is transmitted in the 7OS mini-slot of the first slot, while HARQ ID 1 is transmitted in the 4OS mini-slot. However, in the next slot, the order is reversed; HARQ ID 1 is first transmitted in the 7OS mini-slot, and then HARQ ID 0 is transmitted in the subsequent 4OS mini-slot. This ensures that equal resources are available for both HARQ processes.
[0494] HARQ process repetitions can occur in groups; R of the K repetitions of HARQ ID H can occur consecutively, followed by the transmission of other HARQ processes. Then, the remaining R repetitions can occur for HARQ ID H. This concept is Fig.44 , where HARQ ID 0 is repeated twice, followed by HARQ ID 1. After these HARQ ID 1 transmissions (RV0 and RV1), two more HARQ ID 0 repetitions occur. This configuration allows the gNB some time to respond to the UE with an implicit or explicit acknowledgment. If a transmission from an earlier repetition group is acknowledged, the UE can terminate the repetition of that HARQ process and those resources can be used for other transmissions.
[0495] The allocation of resources for repetitions can be smaller than the allocation of resources for the first transmission. This allows for minimal additional resources, especially if the packet can be successfully decoded with the first transmission in most cases. In most cases, the first transmission can successfully decode more than 90%. Fig.45 An example is shown where the length of the first transmission is 7 OS and the length of the repetition is 4 OS.
[0496] Alternatively, if the SINR conditions are such that the first transmission is likely to fail (such as in a cell edge), it is advantageous to allocate more OS for repetitions. Fig.46 In , the repetitions have longer allocations than the first transmission.
[0497] Permission for multiple configurations of a UE
[0498] The gNB may configure multiple grants for the UE, and the UE may select one of the configured grants for the HARQ process.
[0499] In the following description, the HARQ ID is indicated as a number within each transmission.
[0500] A license can have one of several characteristics.
[0501] For a given HARQ ID and RV, the grants have different timing offsets to enable the UE to select the offset that provides the minimum latency. Fig.47 In , the gNB configures two grants for the UE - CG1 and CG2. Each grant has two HARQ processes with four repetitions. If the UE's HARQ ID 0 is ready for transmission before the reference time t, then the UE uses CG1. If HARQ ID 0 is ready for transmission between the reference time and two time slots, then the UE uses CG2 so that all repetitions can be sent on the grant.
[0502] Although this example shows resource allocation in a slot, it can be generalized to apply to mini-slots and scenarios where only some symbols of a slot are assigned for UL transmission.
[0503] · The permitted time resources can overlap. Fig.47 In the example, the time resources used for CG1 and CG2 completely overlap.
[0504] Alternatively, the granted time resources cannot overlap. Fig.48 In the example, the UE is configured with two CGs – CG1 and CG2. The time resources for CG1 appear in the first half of the slot, while the time resources for CG2 appear in the second half of the slot. The UE can transmit on both CG1 and CG2 within the slot. When switching from one grant to another, the gNB identifies the DMRS change to identify the grant that the UE is to use.
[0505] Fig.48 It is a CG with non-overlapping time resources.
[0506] · Overlapping of licensed frequency resources: For licenses, the frequency resources can even be exactly the same.
[0507] For a given transmission time, each grant provides a transmission opportunity for a different repetition of a HARQ ID or a different HARQ ID to allow the UE to transmit with minimal latency.
[0508] Fig.49An example for the case where a UE is configured for two HARQ IDs 0 and 1 and four RVs is shown in FIG. For the CG, the time resources and frequency resources are the same; the time offsets are different for the HARQ ID / RV. Each HARQ ID is repeated four times with different RVs. Eight different configured grants are sufficient to support the transmission of any HARQ ID and RV at a given opportunity. Each transmission can be a time slot or a mini-time slot.
[0509] If the RV is repeated in a repetition bundle, fewer grants are required to support the transmission of the HARQ ID and the RV.
[0510] In practice, the gNB may configure only a subset of possible CGs to the UE, or it may activate only a subset of CGs at a given time.
[0511] Method for configuring multiple CGs
[0512] The gNB may configure multiple NR-A UL grants to the UE in one of the following ways.
[0513] The gNB explicitly configures multiple grants to the UE via RRC, each with an appropriate timing offset and grant ID. In this case, any configuration changes (e.g., change of frequency) must be applied to each grant. For Type 2 grants, the gNB must activate or deactivate each grant to the UE via DCI and this must be confirmed by the UE via MAC CE.
[0514] The activation and deactivation DCI may carry a grant ID. The grant ID is a few bits and may reuse bits allocated to the HARQ process number and RV, which are set to all 0s in Release 15 for activation and release. Multiple activation or deactivation DCIs may be transmitted in the same monitoring opportunity; therefore, the UE may monitor multiple DCIs with the CS-RNTI.
[0515] Alternatively, the UE is configured to use a scrambling sequence that is unique for each configured grant. The CS-RNTI of the activation / deactivation DCI of the grant is scrambled with a sequence specific to the grant. The UE decodes the PDCCH and checks each candidate grant sequence for a successfully decoded DCI. The UE identifies the grant based on the detected scrambling sequence.
[0516] The gNB configures a "license group" for the UE, where the group consists of G licenses, and all or more of the licenses can be changed with a single update. This requires minimal overhead to update the parameters of the licenses; for example, the frequency resources used for all licenses in the license group can be changed with a single update (either via activation DCI for type 2 or via RRC / MACCE for type 1 licenses). The concept of a license group is described in Fig.50Here, there are M licenses in license group #M, where the offset and DMRS between different licenses are different. Each license can also carry an ID. All other parameters can be the same across licenses.
[0517] If all permissions in a group are type 1, then the group permission is type 1. If all permissions in a group are type 2, then the permission is type 2.
[0518] The gNB provides the offset to the UE in one of the following ways.
[0519] ·The time offset given by the RRC parameter timeDomainOffset is the RRC configured for a type 1 grant group. For grant groups with grants that differ primarily in offset, the grant group RRC can be configured as one information element providing multiple grants to the UE. A list of length G for DMRS configuration, a grant ID, and a timing offset (timeDomainOffset) is provided to the UE to indicate that the group grant contains G grants. An example of a grant group RRC configuration is shown in Example 1 of the Appendix. The IE GrantGroupConfig is used to configure the grant group for grant transmission of type 1 and type 2 uplink configurations.
[0520] Alternatively, licenses with different parameters may be grouped into license groups; here, frequency resources, MCS, etc. may differ between licenses. Thus, licenses may be configured individually but may be grouped into license groups for managing each of the licenses. For example, for a type 2 group license, power control may be commonly applied to all licenses in the group license.
[0521] The gNB may provide the following License Group CE consisting of a License Group ID and a list of license IDs of this group belonging to Type 1 licenses as shown in Example 2 of the Appendix.
[0522] If the gNB allows a license to be part of more than one group license, the gNB can have more flexibility depending on the traffic and load in the system. Hence, a license (child) can have multiple group licenses (parents). Hence, a license is also updated if an update is applied to any of its parents; the license will be updated based on the latest update to the parent group license.
[0523] o For type 2 licenses, all licenses in a license group can be activated / deactivated together; the activation and deactivation DCIs have fields to indicate the affected licenses in one of the following ways.
[0524] • This field is the Grant ID field; when the Grant ID of one of the grants is indicated in this field, the DCI applies to all grants in the grant group.
[0525] • This field is the License Group ID; when the Group field is present, the DCI applies to all licenses in the license group with the specified ID. The License Group ID is useful when the UE can have multiple license groups.
[0526] Since the grant ID is configured via RRC, the activation DCI can only provide the timing offset for the grant. This is done via the Time domain resource assignment field (format 0_1DCI). This field is an index into a table of multiple rows, where each index provides the time domain resource assignment for each grant. Here, parameters such as S and L can be the same for the grant, but the offset K 2 is different for each grant. An example where the group grant has four grants is given in Table 2 of the Appendix. The index provides the starting symbol and length assignment for the PUSCH, and K 2 The value provides an offset for each license.
[0527] Alternatively, for a type 2 group of grants, the activation DCI activates only a subset of the grants by indicating those specific grants and those offsets. Fig.51 Shown in.
[0528] A table similar to Table 2 may be used and the index may be indicated in the activation DCI. The table consists of multiple rows, where a row may indicate one or more licenses, as shown in the example of Table 3 of the Appendix. In Table 3, indexes 1-8 show activation of only two licenses (only license 1 and license 2), while the remaining indexes show activation of all four licenses in the group license.
[0529] o Alternatively, for type 2 grants, the RRC configuration may provide a list of offsets for grants, but the activation DCI activates only certain grants by indicating a subset of the offsets.
[0530] A group grant can also contain a mix of Type 1 and Type 2 grants. The advantage of this configuration is that it can adapt quickly to traffic demand. A UE can have a Type 1 grant; but if more grants are required to support latency and data rate, the gNB can allocate additional grants through Type 2 grants that can be part of the same group grant. Thus, the UE can switch from a Type 1 grant to a Type 2 grant, or from a Type 2 grant to a Type 1 grant, to retransmit a HARQ process or send a repetition.
[0531] Managing group license resources across different frequency regions
[0532] A group license may be configured in multiple frequency zones, where a frequency zone is a sub-band within a wideband BWP ( Fig.52A ), or the frequency regions are separate BWPs ( Fig.52B).
[0533] The following examples are discussed in the context of NR-U, but can be applied to eURLLC and eV2X. There can be scenarios where the gNB may receive interference in some frequency regions due to another node, but the UE may not hear the interference. If the UE transmits autonomously on those frequency bands, then the gNB may not be able to receive the UE's transmissions. We propose in this paper to enable the gNB to dynamically suspend grants in such resources. The gNB can indicate a suspension via a "suspend-DCI". A suspension temporarily deactivates a Type 1 or Type 2 grant. This DCI can carry one of the following fields.
[0534] A group license ID field, indicating which group license must be suspended
[0535] The license ID field indicates which license is suspended. In addition, if a license is suspended, other licenses in its license group may also be suspended.
[0536] BWP-ID or Sub-band ID. All grants whose frequency resources overlap with the indicated BWP-ID or Sub-band ID are suspended.
[0537] The pause state can be ended in one of the following ways.
[0538] When a suspend-DCI for a grant is received, the UE timer is set to the RRC configured value. The timer decrements over time. When it expires, the UE may resume using that grant.
[0539] • Transmit Resume-DCI to indicate on which grant transmission can be resumed. Resume-DCI may use the same RNTI as Suspend-DCI and may have the same length and format as Resume-DCI. A one-bit field in the DCI may indicate "Suspend" or "Resume" status.
[0540] • Suspension - The DCI carries a field indicating the duration that the UE may not have access to a grant.
[0541] Fig.53A The use of a timer to pause and resume NR-AUL transmission on a grant is illustrated. Fig.53B The use of recovery-DCI is illustrated.
[0542] Fig.54A and Fig.54B It is the procedure of NR-AUL using the resume-DCI suspension grant (A) using a timer (B).
[0543] When the gNB sends a suspend-DCI for a grant, the UE may already be using that grant. Note that the suspend-DCI may be received by the UE in a different BWP or subband in TDD or on a different frequency band in FDD. In that case, the UE may perform one of the following actions.
[0544] • The UE immediately stops transmitting on the suspended grant and releases the channel.
[0545] • The UE transmits for a predetermined duration, such as until the next slot boundary location, and then suspends transmission.
[0546] The UE completes the transmission of the current NR-AUL PUSCH HARQ process and then releases the channel. Even if the UE obtains the COT, the UE cannot transmit the configured repetitions for that HARQ process.
[0547] If the UE suspends an ongoing HARQ process, it may reset its nr-aul-retransmissionTimer timer for that HARQ process and may retransmit that process on another grant without waiting for the NR-AUL timer to expire or the NR-AUL-DFI.
[0548] The UE needs to perform LBT to regain channel access and resume transmission on the suspended grant.
[0549] Fig.55A A pause during an ongoing NR-AUL transmission is illustrated when a Pause-DCI is received, wherein the transmission is immediately interrupted. Fig.55B The diagram illustrates the situation where transmission is interrupted at a time slot boundary.
[0550] Suspending and resuming DCI does not need to be acknowledged by the UE (unlike the MAC CE based acknowledgement of activating DCI).
[0551] The PAUSE-DCI may be transmitted as follows.
[0552] As GC-PDCCH, so that multiple UEs can be notified simultaneously
[0553] As UE-specific DCI, such as DCI scrambled with NR-AUL-RNTI or CS-RNTI or C-RNTI
[0554] RNTI for CG PUSCH
[0555] If the UE can choose from multiple CGs and only DMRS is the way to identify the UE identity and the CG of the UE, some performance loss may occur due to false alarms. To increase robustness, we propose in this paper that the UE uses a CG-RNTI specific to the CG to transmit the PUSCH, where the CRC used for the PUSCH is scrambled by the CG-RNTI. The gNB can configure a unique RNTI per CG for each UE. For example, the UE can have a CS-RNTI per CG.
[0556] Alternatively, the UE may have only one CS-RNTI, so that it can use the CS-RNTI to receive activation / deactivation, DFI, etc. (rather than monitoring multiple CS-RNTIs), but the CRC may be scrambled on the PUSCH using a mask unique to the CG. The gNB configures this mask to the UE for each CG RCC.
[0557] UCI for syncing CG
[0558] If DMRS is limited, then the same DMRS can be assigned to multiple UEs. One candidate use case is the industrial IoT scenario, where hundreds of machines or sensors can be deployed. In this case, DMRS is not sufficient to identify the UE. Therefore, the UE can carry the UCI with its ID (such as CS-RNTI or C-RNTI) on the CG so that the gNB can identify it by decoding the UCI.
[0559] Repetition across CGs
[0560] For reliable transmission, it is desirable to ensure K repetitions of the HARQ process transmission. The UE may not be able to transmit one or more repetitions on the CG due to resource preemption, or due to scheduled grants in those resources or due to other signals in the resources such as SSB or DRS. We propose in this paper that the missed repetitions on CGi can be completed on CGj, for example, the UE can switch the CG from the i-th grant to the j-th grant to complete the K repetitions.
[0561] As seen previously, in the following description, the numbers in the transmissions in the figures represent HARQ IQ, while RP represents repetition within a bundle.
[0562] For example, Fig.56As shown in , say CG1, CG3, CG5, and CG7 are activated to the UE. The UE may start transmission on CG1, but may not be able to transmit RV2 of HARQ ID 0 on CG1 due to DL signals or non-CG resources, but it may transmit RV3 of HARQ ID 0 on CG1. In this case, since those resources are available to the UE, the UE switches to CG3 immediately after transmitting RV3 and transmits RV2 of HARQ ID 0. The ticks indicate the transmissions of the UE.
[0563] The UE may switch to the grant that provides the minimum delay to complete the K repetitions.
[0564] As another example of UE behavior, Fig.57 As shown in , the UE transmits on the current CG and does not transmit until it switches when it misses the opportunity to transmit on the new CG. Here, type 2 grants CG1 and CG5 have been activated for the UE. After transmitting RV3 on CG1, it does not transmit until it has the opportunity to transmit RV2 on CG5, but there is a gap of non-transmission between the transmissions on the two CGs.
[0565] Alternatively, when a transmission is missed on a grant, the UE immediately exits that grant and looks for a grant where it continued the missed transmission. Fig.58 In , the UE missed RV2 of CG1 for HARQ ID 0. It switches and transmits RV2 and RV3 of HARQ ID 0 on CG5.
[0566] The gNB will detect the UE’s CG from the DMRS. In addition, if the UE behavior for handover is defined, the gNB has less burden of blindly detecting the new CG.
[0567] When a UE misses a transmission and switches to a different CG, it may transmit the same RV as it transmitted in the earlier CG. Fig.59 As shown in , the UE can transmit RV0 and RV1 on CG1. Since resources are not available for RV2 on CG1, the UE switches to CG5 and transmits RV0 and RV1 again on CG2. The repetition stops after reaching 4. This keeps the latency to a minimum.
[0568] Early termination of repetitions
[0569] For latency sensitive applications like eURLLC and for time constrained applications like NR-U (COT is restricted), it is advantageous to support early termination of repetitions. If the gNB can decode the transmission of a HARQ ID from fewer repetitions, then it can transmit an Ack to the UE and the UE cannot continue with repetitions for that HARQ ID.
[0570] Note that retransmission is different from repetition; retransmission occurs when a Nack is received or a timer such as nr-aul-retransmissionTimer expires from the time of the initial transmission. However, repetition occurs at most K times, or repetition may not occur until an Ack is received.
[0571] Upon termination, the UE may transmit a different HARQ ID to which it may switch to a different CG. Fig.60A and Fig.60B An example is shown in FIG, where the UE transmits HARQ ID 0 and receives an Ack, at which point the UE terminates the transmission of ID 0 before completing four repetitions. Each transmission can be a slot or a simulated slot, such as 2OS, 4OS, and 7OS long transmissions. Fig.60A In , the UE monitors the CORESET at the beginning of each time slot. If the UE has something in that buffer, then instead of wasting the transmission opportunity, the UE switches to CG8 to start transmission of HARQ ID #1. Fig.60B In , the UE transmits two mini-slots in each slot and monitors the CORESET at the beginning of the slot for DCI. After the first two transmissions in the repetition bundle, upon receiving the Ack for HARQ ID 0, the UE does not transmit repetitions RP2 and RP3, but switches to another CG to transmit HARQ ID 1.
[0572] Retransmission on CG
[0573] If a UE has multiple CGs configured to it and does not receive an acknowledgment of a transmission of a HARQ ID within a certain duration, then it can retransmit the HARQ ID on a different CG, for example, we propose in this paper that the retransmission can occur on a different CG than the original transmission. The UE can select a new CG in a way that minimizes the latency of the retransmission.
[0574] The concept is Fig.61 . The UE transmits HARQ ID 0 on CG1 with four repetitions. It does not receive an acknowledgment in the form of an explicit Ack or a scheduled UL grant. The configuredGrantTimer set during the HARQ ID transmission is decremented as the UE transmits on CG1 and eventually expires. Upon expiration, the UE identifies CG7 as a grant that provides an opportunity to transmit HARQ ID 0. Since all K repetitions can be transmitted on CG7, the UE switches to CG7 and retransmits HARQ ID 0.
[0575] CG repeated frequency hopping
[0576] Depending on the traffic in the cell, the gNB may schedule multiple UEs on the same resource. If multiple UEs transmit simultaneously, collisions between UEs may occur. To be robust to collisions, the gNB may schedule UE-specific frequency hopping patterns for the repetitions in a grant to reduce the chances of collisions between two UEs, e.g., even if a UE collides in one transmission, other repetitions may not collide. Fig.62 An example is shown in FIG. 1 , where UE1 has a CG with two HARQ processes 0 and 1, each with four repetitions. UE1 ID 0, RV 1 The transmission conflicts with the transmission of UE2. UE1's ID 1, RV 0 The transmission collides with the transmission of UE2. The other repetitions of UE1 do not collide, so the gNB has a good chance to correctly decode the transmission.
[0577] Note that the gNB can identify conflicts from the DMRS of the UE. The DMRS sequences of the UE can be orthogonal or can be on different ports and can be distinguished by the gNB.
[0578] The frequency hopping pattern is configured for Type 1 CG through RRC, and the frequency resources can be bound to the timing of transmission (such as slot or mini-slot timing).
[0579] For a Type 2 grant, the frequency hopping pattern may be provided to the UE in the following manner.
[0580] Configured for Type 2CG via RRC in the form of an offset from the reference frequency. The reference frequency is provided in the activation DCI.
[0581] RRC can configure multiple frequency hopping modes for the CG, and the activation DCI can indicate the frequency hopping mode to be used.
[0582] Provide frequency hopping mode by activating DCI.
[0583] CG's repeated time jumps
[0584] CG resources can also support time hopping to be more robust to collisions. Fig.63 As shown in , the transmission order and repetition of HARQ IDs can vary based on resource time and in a UE-specific manner. Here, UE1 and UE2 are configured with CG resources on the same frequency and time. Assuming that UE1 and UE2 only have HARQ process 0 to transmit, then their transmissions collide only on the first transmission. Therefore, the gNB has a good chance of recovering the transmissions of both UEs. In this example, the HARQ processes are transmitted in an interleaved manner in each repetition set.
[0585] We define the total time over which H processes can be transmitted as Pharq. We also define the total time over all configured HARQ processes and repeated transmissions as Ptotal - this is the total periodicity between all HARQ processes configured for the UE. These parameters are Fig.64 If H HARQ processes and K repetitions are supported, the ID and RV can be generated by the following equations.
[0586] ·[HARQ_ID]=F1([floor(CURRENT_symbol / Pharq)]modulo H)
[0587] ·[HARQ_RV]=floor([floor(CURRENT_symbol / Ptotal)]modulo H*K) / K)
[0588] Here, F1(.) is a function that provides a pseudo-random interleaver. F1(.) generates a pseudo-random interleaver of length H that is applied to each set of H transmissions (within a single repetition of the HARQ ID). All HARQ_RVs within a repetition set are identical.
[0589] exist Fig.65 An alternative way to time-hop across HARQ IDs and repetitions is shown in . Here, repetitions are jumped across the entire cycle of four HARQ processes. This provides more randomness, but the latency across all HARQ IDs may not be uniform because repetitions of one ID may be too far apart from each other.
[0590] like Fig.66 As shown in , the randomization spans H*K transmissions. HARQ_ID and HARQ_RV can be generated by the following equations.
[0591] ·[HARQ_ID,HARQ_RV]=F2([floor(CURRENT_symbol / Ptotal)]modulo(H*K))
[0592] F2(.) is a function that provides a pseudo-random interleaver. F2(.) generates a pseudo-random interleaver of length H*K.
[0593] Functions F1(.) and F2(.) are a way to randomize the position of the HARQ ID and RV over time. They can be configured as a list of indices passed through RRC to the UE. Alternatively, the pseudo-randomness can be a function of time and can be derived from an m-length sequence or golden sequence generator from its state or output sequence (thus making it time-varying). The sequence generator can be initialized by the gNB in a UE-specific way so that different UEs have different random patterns.
[0594] Sensing-based CG selection
[0595] We propose in this paper that a UE can sense the channel to avoid collision with another UE in applications such as eV2X and NR-U. The gNB can configure multiple CGs for the UE; the UE selects a CG resource; if the UE senses a transmission from another node in that resource, then the UE can switch to a different CG where it senses an idle channel.
[0596] The UE can sense the channel for the first transmission of the HARQ process. If the channel is not available, the UE can select another CG where it can obtain channel access to transmit at least k repetitions (k <= K). This concept is Fig.67 Here, the UE gains access to CG1 but not to CG2; therefore, it transmits on CG1 and completes K=4 repetitions on CG1.
[0597] The self-delay based backoff may be randomly generated from a predefined or preconfigured list of random values ranging from a value greater than 0 to a multiple of the OS including a fraction of a symbol. Due to the self-delay, some OS may not be available for UL transmission. Therefore, the UE may rank match the PUSCH accordingly. However, the repetition may have more OS and the UE will rank match those resources.
[0598] In fractional self-delay, the UE may use the CP extension of the next symbol to occupy a fraction of the OS.
[0599] The UE may use random backoff to gain channel access to minimize the possibility of conflict. The UE may attempt to access multiple CGs simultaneously in one of the following ways.
[0600] ·The UE generates a single self-delay value. Until this value is reached, the UE senses the channel on all CGs. If one or more CGs are found to be available, then one CG is selected for transmission. This concept is Fig.68A Shown in.
[0601] ·The UE generates multiple self-delay values, one for each CG. It uses the corresponding self-delay value to sense each channel. The UE can select the CG available for the channel with the minimum delay. This concept is Fig.68B Shown in.
[0602] If the UE has to switch to a different CG, then the UE has to perform channel sensing on that CG. On the CG accessed by the UE, the UE can transmit in one of the following ways.
[0603] ·The UE can transmit on the CG for time T and then exit the CG. To regain access to the CG, it must perform sensing again. This concept is Fig.69A This ensures that other UEs also have the opportunity to access those resources. The gNB configures T to the UE via RRC. If the UE has multiple CGs, then the configuration can be for each CG.
[0604] Alternatively, the UE may use a timer "cgAccessTimer" which is set at the start of a CG access or when accessing a CG. The cgAccessTimer decrements during use of the CG. During intermittent DL and non-CG UL resources, the cgAccessTimer is frozen. When the cgAccessTimer expires, the UE leaves the CG and has to sense the channel to gain access to it again. If intermittent DL or non-CG UL resources are important during channel access, this ensures that the UE obtains sufficient resources. This concept is discussed in Fig.69B Shown in.
[0605] The UE can transmit up to N HARQ processes and their repetitions K on a CG, and then the UE leaves the CG. The gNB configures N and K to the UE via RRC. If the UE has multiple CGs, then the configuration can be per CG.
[0606] Once a UE has accessed a channel for a CG, the UE may make UL transmissions on the resource without self-delay even if there are DL signals or scheduled UL resources between transmissions, e.g. Fig.70 Here, the UE self-extends in slot 0 and gains access to the CG resources. Even if intermittent DL and non-CGUL symbols / slots occur, the UE can still access other CG resources without sensing the channel.
[0607] Other UEs that may attempt to access the resources of UE1's CG have non-zero self-delay and will detect UE1's transmission and avoid transmitting and colliding on those resources.
[0608] Based on the above, an embodiment of a method for operating a communication system is provided below. Fig.71. The gNB configures the UE for PUSCH transmission with one or more configured grants. The configured grants provide time-frequency resources for PUSCH. The time resources may be periodic. Additionally, the time resources are continuous for unlicensed channel operation, enabling a device to gain channel access and perform continuous PUSCH transmissions, after which it relinquishes channel access. After selecting a transmission time opportunity in the configured granted resources, the UE transmits one or more HARQ processes. The UE indicates one or more of the HARQ process ID, its redundancy version, and new data indicator information for the HARQ process on the control channel. The control channel may be multiplexed with the PUSCH resources so that the gNB may decode the control information on the control channel and decode the data on the PUSCH accordingly. The UE may also send its identifier in the form of a Radio Network Temporary Identifier (RNTI) over the control channel.
[0609] The UE receives feedback from the gNB on a feedback indicator for one or more PUSCH HARQ processes. If a NACK for a HARQ process is indicated to the UE, the UE may retransmit the HARQ process on a configured grant. If the UE receives an explicit negative acknowledgment from the gNB either through the feedback indicator or through a scheduled grant from the dynamic scheduling of retransmissions for that HARQ process ID or by no indication within a configured duration, the UE may assume a NACK. The UE has a timer per transmitted HARQ process ID to track this duration. When a HARQ process is transmitted via PUSCH, the timer is set. If the timer expires but no feedback is received, then that HARQ process may be retransmitted on a configured grant. The configured grant used for the retransmission does not have to be the same as the grant used for the first transmission.
[0610] The ACK / NACK on the feedback indicator may be provided as a bitmap, where each bit represents an acknowledgement of each code block group CBG for one or more transport blocks (TBs) for a HARQ process. The UE may retransmit only the CBGs of the HARQ process that are negatively acknowledged, and the UE may indicate the included CBGs in the control information on the control channel.
[0611] In some applications, the UE may indicate the resources on which the gNB may transmit the feedback indicator. The UE may indicate this resource via a control channel multiplexed with the PUSCH. The UE may indicate this information on multiple PUSCH transmissions in the configured grants via the corresponding control channel. The feedback may include acknowledgments for multiple HARQ processes, including HARQ processes that may have been transmitted via dynamically scheduled grants. The feedback indicator may also provide other information to the UE, such as a command to adjust the power for the PUSCH transmission. The feedback indicator may carry a UE-specific identifier and may be the same as the RNTI used by the UE for control channel transmissions.
[0612] Another embodiment of a wireless system is provided in which the gNB configures the UE with multiple configured grants, each grant identified by a "configured grant ID". The multiple configured grants may be configured as a group of grants with multiple common parameters. At least some of the parameters will differ between grants such as in a group - for example, a configured grant ID and DMRS will be configured separately for each configured grant. Multiple configured grants may be activated together. Multiple configured grants may be deactivated simultaneously. The UE may autonomously select a configured grant to use for one or more HARQ processes for transmitting a PUSCH. The demodulation reference signal (DMRS) of the PUSCH transmitted on the configured grant is associated with the configured grant ID. Thus, upon receiving the DMRS, the gNB may determine the autonomously selected configured grant. The UE may transmit the configured grant ID of the selected configured grant via control information multiplexed with the PUSCH resources.
[0613] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation of cellular technology, which is called New Radio (NR), also known as "5G". The development of the 3GPP NR standard is expected to include the definition of the next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to include new, non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-6 GHz flexible radio access, leveraging design optimizations specific to cmWave and mmWave.
[0614] 3GPP has identified a variety of use cases that NR is expected to support, resulting in various user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, ubiquitous 50+Mbps, ultra-low-cost broadband access, in-vehicle mobile broadband), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, power saving), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car ecalls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, and virtual reality, among others. All of these use cases and others are considered in this article.
[0615] Fig.72An embodiment of an example communication system 100 is illustrated in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (generally or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e Figures 72-76 , but it should be understood that for various use cases contemplated for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, truck, train or airplane, etc.).
[0616] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks (such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112). The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b and / or TRPs (transmission and reception points) 119a, 119b to facilitate access to one or more communication networks (such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112). The RRHs 118a, 118b may be any type of device configured to interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node-Bs (Node Bs), eNode Bs, home Node Bs, home eNode Bs, site controllers, access points (APs), wireless routers, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.
[0617] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may therefore use multiple transceivers for each sector of the cell.
[0618] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).
[0619] The base station 114b may communicate with one or more of the RRHs 118a, 118b and / or TRPs 119a, 119b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).
[0620] The RRHs 118a, 118b and / or the TRPs 119a, 119b may communicate with one or more of the WTRUs 102c, 102c via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).
[0621] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDPA) and / or High Speed Uplink Packet Access (HSUPA).
[0622] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advance (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology.
[0623] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.
[0624] Fig.72 The base station 114c in the example may be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, etc. In an embodiment, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Fig.72 As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.
[0625] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication).
[0626] Although not in Fig.72 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.
[0627] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet Protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.
[0628] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.72 The WTRU 102e shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.
[0629] Fig.73 1 is a block diagram of an example apparatus or device (such as, for example, WTRU 102) configured for wireless communication according to the embodiments described herein. Fig.73As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments. Moreover, the embodiments contemplate that the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and a proxy node, etc.), may include Fig.73 Some or all of the elements depicted in and described herein.
[0630] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.73 The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
[0631] The transmission / reception element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an embodiment, the transmission / reception element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmission / reception element 122 may be a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmission / reception element 122 may be configured to transmit and receive RF and light signals. It should be appreciated that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless signals.
[0632] In addition, although the transmit / receive element 122 is Fig.73Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.
[0633] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.
[0634] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In an embodiment, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0635] The processor 118 may receive power from the power source 134 and may be configured to distribute power to and / or control other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.
[0636] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.
[0637] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.
[0638] The WTRU 102 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes), etc. The WTRU 102 may be connected to other components, modules or systems of such devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 138).
[0639] Fig.74 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Fig.74As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
[0640] like Fig.74 As shown, Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node B 140a, 140b, 140c connected thereto. In addition, each of RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.
[0641] Fig.74 The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it should be appreciated that any of these elements may be owned and / or operated by an entity other than a core network operator.
[0642] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
[0643] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0644] As described above, core network 106 may also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.
[0645] Fig.75 1 is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.
[0646] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
[0647] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Fig.75 As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.
[0648] Fig.75The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and / or operated by an entity other than a core network operator.
[0649] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
[0650] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.
[0651] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0652] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.
[0653] Fig.76 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As discussed further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.
[0654] like Fig.76 As shown in the figure, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.
[0655] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.
[0656] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transfer between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
[0657] like Fig.76 As shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes protocols for facilitating, for example, data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.
[0658] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.
[0659] Although not in Fig.76 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.
[0660] This article describes and Figures 71-75 The core network entities shown in are identified by the names given to those entities in certain existing 3GPP specifications, but it should be recognized that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Figures 72-76 The specific network entities and functionality described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or in the future.
[0661] Fig.77 is a block diagram of an exemplary computing system 90 in which Figures 72-76103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, wherever or in any manner such software is stored or accessed. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor different from the main processor 91 that may perform additional functions or assist the processor 91. Processor 91 and / or coprocessor 81 may receive, generate and process data related to the methods and apparatus disclosed herein.
[0662] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.
[0663] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.
[0664] In addition, the computing system 90 may include a peripheral device controller 83 that is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .
[0665] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.
[0666] Additionally, computing system 90 may include communications circuitry, such as a network adapter 97, which may be used to connect computing system 90 to an external communications network, such as a Figures 72-76 The RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112) of the present invention can be used to enable the computing system 90 to communicate with other nodes or functional entities of those networks. Alone or in combination with the processor 91, the communication circuit system can be used to perform the transmission and reception steps of certain devices, nodes or functional entities described herein.
[0667] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassette, tape, disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.
[0668] appendix
[0669] Table 1
[0670] Abbreviations
[0671]
[0672]
[0673]
[0674]
[0675]
[0676] Table 2 PUSCH time domain resource allocation for group grant with four grants
[0677]
[0678] Table 3 PUSCH time domain resource allocation for group grant
[0679]
[0680] GrantGroupConfig Information Element - Example 1
[0681]
[0682]
[0683]
[0684] GrantGroupConfig Information Element - Example 2
[0685]
Claims
1. A wireless transmit / receive unit (WTRU), comprising a processor and a memory, wherein the processor and the memory are configured to: receiving one or more configured grants, each of the one or more configured grants comprising an indication of periodic transmission resources, each periodic transmission resource comprising time and frequency resources for transmission of a hybrid automatic repeat request (HARQ) process; sending a transmission according to a first configured grant of the one or more configured grants, wherein the transmission is associated with one or more HARQ processes and control information, the control information comprising a HARQ process identifier (ID) and a redundancy version (RV) for each of the one or more HARQ processes, wherein an amount of resources used for the control information is based on an offset value; receiving downlink control information (DCI) using the WTRU ID, the DCI comprising a downlink feedback indicator and a bitmap, wherein each bit in the bitmap indicates feedback for a corresponding HARQ process of the one or more HARQ processes; as well as Data associated with a first HARQ process of the one or more HARQ processes is retransmitted upon determining a negative acknowledgement of the first HARQ process based on a bitmap of a previous transmission of data associated with the first HARQ process and a downlink feedback indicator.
2. The WTRU of claim 1 , wherein the processor and the memory are further configured to: starting a retransmission timer after transmitting data associated with the first HARQ process; If no acknowledgement is received before the retransmission timer expires, data associated with the first HARQ process is retransmitted according to the first configured grant.
3. The WTRU of claim 1 , wherein the processor and the memory are further configured to determine an acknowledgment for a second HARQ process via a DCI, wherein data associated with the second HARQ process is not transmitted via the first configured grant.
4. The WTRU of claim 1 , wherein the processor and the memory are further configured to indicate a time resource for the DCI granted for two or more consecutive transmissions with respect to the first configuration.
5. The WTRU of claim 1 , wherein the processor and the memory are further configured to: receiving, from a second device, a configuration for each of a plurality of configured licenses, each configuration including a license ID of the configuration, the configurations being distinguished from one another by their reference signals; selecting a first configured license from the plurality of configured licenses; and Selection of the permission of the first configuration is indicated to the second device via a reference signal.
6. The WTRU of claim 5, wherein the second device is a gNB.
7. The WTRU of claim 5, wherein the processor and the memory are further configured to receive a joint activation of the plurality of configured licenses via a command in a single control signal.
8. The WTRU of claim 7, wherein the processor and the memory are further configured to receive a joint deactivation of the plurality of configured grants via a command in a single control signal.
9. The WTRU of claim 5 , wherein the processor and the memory are further configured to select a first configured grant from the plurality of configured grants to transmit a HARQ process based at least in part on the first configured grant providing the lowest latency.
10. The WTRU of claim 1, wherein a number of coded modulation symbols per layer associated with control information transmission is determined based in part on the offset value.
11. A base station comprising a processor and a memory, wherein the processor and the memory are configured to: sending one or more configured grants, each grant of the one or more configured grants comprising an indication of periodic transmission resources, each periodic transmission resource comprising time and frequency resources for transmission of a hybrid automatic repeat request (HARQ) process; receiving a transmission according to a first configured grant of the one or more configured grants, wherein the transmission is associated with one or more HARQ processes and control information, the control information comprising a HARQ process identifier (ID) and a redundancy version (RV) for each of the one or more HARQ processes, wherein an amount of resources used for the control information is based on an offset value; transmitting downlink control information (DCI) using the WTRU's ID, the DCI comprising a downlink feedback indicator and a bitmap, wherein each bit in the bitmap indicates feedback for a corresponding HARQ process of the one or more HARQ processes, and wherein the downlink feedback indicator and the bitmap indicate a negative acknowledgement of a previous transmission of data associated with a first HARQ process of the one or more HARQ processes; as well as A retransmission of data associated with a first HARQ process of the one or more HARQ processes is received.
12. The base station of claim 11, wherein the processor and the memory are configured to send an acknowledgement for a second HARQ process via a DCI, wherein data associated with the second HARQ process is not transmitted via the first configured grant. 13 . The base station of claim 11 , wherein the processor and the memory are configured to receive a time resource granting DCI for two or more consecutive transmissions regarding a first configuration.
14. The base station of claim 11, wherein the processor and the memory are configured to: transmitting a configuration for each of a plurality of configurations of grants, each configuration including a grant ID of the configuration, the configurations being distinguished from one another by their reference signals; and An indication of selection of a grant of the first configuration is received via a reference signal.
15. The base station of claim 14, wherein the processor and the memory are configured to send the joint deactivation of the plurality of configured grants via a command in a single control signal.
16. The base station of claim 11, wherein a number of coded modulation symbols per layer associated with control information transmission is determined based in part on the offset value.
17. A method performed by a wireless transmit / receive unit (WTRU), comprising: receiving one or more configured grants, each of the one or more configured grants comprising an indication of periodic transmission resources, each periodic transmission resource comprising time and frequency resources for transmission of a hybrid automatic repeat request (HARQ) process; sending a transmission according to a first configured grant of the one or more configured grants, wherein the transmission is associated with one or more HARQ processes and control information, the control information comprising a HARQ process identifier (ID) and a redundancy version (RV) for each of the one or more HARQ processes, wherein an amount of resources used for the control information is based on an offset value; receiving downlink control information (DCI) using the WTRU ID, the DCI comprising a downlink feedback indicator and a bitmap, wherein each bit in the bitmap indicates feedback for a corresponding HARQ process of the one or more HARQ processes; as well as Data associated with a first HARQ process of the one or more HARQ processes is retransmitted upon determining a negative acknowledgement of the first HARQ process based on a bitmap of a previous transmission of data associated with the first HARQ process and a downlink feedback indicator.
18. The method of claim 17, wherein a number of coded modulation symbols per layer associated with control information transmission is determined based in part on the offset value.
19. A wireless transmit / receive unit (WTRU), comprising a processor and a memory, wherein the processor and the memory are configured to: receiving a radio resource control (RRC) message from a network including a grant configuration, wherein the grant configuration is associated with a plurality of uplink (UL) grants; receiving downlink control information (DCI) from a network, wherein the DCI includes an indication that two or more UL grants of the plurality of UL grants are to be deactivated; and The two or more UL grants of the plurality of UL grants are deactivated based on the received DCI.
Citation Information
Cited By
Consolidated feedback indication and feedback transmission
US12418926B2
Consolidated feedback indication and feedback transmission
US20240414723A1