User Equipment and System for Performing Transmitting and Receiving Operations - Patent application

Abstract

To facilitate improving the flexibility in the support of transport block repetitions without additional signaling overhead.SOLUTION: At least one row of a table defined by a PUSCH time domain resource allocation list IE comprises a first set of values related to allocated time-domain resources for a plurality of PUSCH transmissions. User equipment receives DCI carrying a time-domain resource assignment field with a value m, where the value m provides a row index m+1 to the table configured by RRC. The user equipment determines allocated time-domain resources for the plurality of PUSCH transmissions based on an index of a slot carrying the DCI and on the first set of values included in the indexed row of the table. The user equipment selects transport blocks of data to be carried in the plurality of PUSCH transmissions, and transmits the plurality of PUSCH transmissions using the time-domain resources.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present disclosure relates to transmitting and receiving signals in communication systems, and more particularly to methods and apparatus for such transmitting and receiving. [Background technology]

[0002] The 3rd Generation Partnership Project (3GPP) is working on technical specifications for the next generation of cellular technology, also known as the fifth generation (5G), which includes "New Radio" (NR) radio access technology (RAT), operating in the frequency range up to 100 GHz.

[0003] NR is the successor to technologies represented by Long Term Evolution (LTE) and LTE Advanced (LTE-A). NR is planned to facilitate the provision of a single technical framework that addresses several defined usage scenarios, requirements, and deployment scenarios, including enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC).

[0004] For example, deployment scenarios for eMBB may include indoor hotspots, dense urban areas, suburban areas, urban areas, and high-speed areas. Deployment scenarios for URLLC may include industrial control systems, mobile health management (remote monitoring, diagnosis, and treatment), real-time control of vehicles, and wide-area monitoring and control systems for smart grids. Deployment scenarios for mMTC may include scenarios using a large number of devices with low-latency data transmission, such as smart wearables and sensor networks.

[0005] eMBB and URLLC services are similar in that they both require extremely high bandwidth, but URLLC services require extremely low latency and extremely high reliability. In NR, the physical layer is based on time-frequency resources (such as Orthogonal Frequency Division Multiplexing (OFDM) in LTE) and supports multi-antenna operation.

[0006] In systems such as LTE and NR, further improvements and options may facilitate efficient operation of the communication system and certain devices associated with the system. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] Technical Report TR 38.804 v14.0.0 [Non-patent document 2] TS 38.300 v.15.0.0 [Non-patent document 3] 3GPP TR 38.801 v14.0.0, “Study on new radio access technology: Radio access architecture and interfaces” [Non-patent document 4] Recommendation ITU-R M.2083: IMT Vision - "Framework and overall objectives of the future development of IMT for 2020 and beyond", September 2015 [Non-patent document 5] RP-172115 [Non-patent document 6] 3GPP TR 38.913 V15.0.0 ,”Study on Scenarios and Requirements for Next Generation Access Technologies” [Non-Patent Document 7] RP-172817 [Non-patent document 8] 3GPP TS 38.211 “NR; Physical channels and modulation” V15.4.0 [Non-Patent Document 9] TS 38.212 “NR; Multiplexing and channel coding” V15.4.0 [Non-Patent Document 10] TS 38.213 “NR; Physical layer procedures for control” V15.4.0 [Non-Patent Document 11] TS 38.214 “NR; Physical layer procedures for data” V15.4.0 [Non-Patent Document 12] RP-181477, “New SID on Physical Layer Enhancements for NR URLLC”, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell [Non-Patent Document 13] 3GPP TS 22.261 “Service requirements for next generation new services and markets” V16.4.0 Summary of the Invention [Problem to be solved by the invention]

[0008] One non-limiting exemplary embodiment facilitates improved flexibility in supporting transport block repetition without additional signaling overhead. [Means for solving the problem]

[0009] In one embodiment, the techniques disclosed herein provide a user equipment (UE) comprising a receiver, a processor, and a transmitter, wherein the receiver, in operation, receives a physical uplink shared channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion.

[0010] In operation, the processor configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, at least one row including a first set of values associated with time domain resources allocated for the multiple PUSCH transmissions.

[0011] In operation, the receiver receives downlink control information (DCI) signaling conveying a time domain resource allocation field with value m, which provides row index m+1 in a table configured by the RRC.

[0012] In operation, the processor determines time domain resources to be allocated for the multiple PUSCH transmissions based on an index of a slot carrying the received DCI and a first set of values included in an indexed row of a table configured by the RRC that is associated with the time domain resources to be allocated.

[0013] In operation, the transmitter selects a transport block of data to be carried in the multiple PUSCH transmissions, and transmits the multiple PUSCH transmissions respectively using the determined allocated time domain resources, the transport block of data being selected based on at least one second parameter included in an indexed row of the table configured by the RRC, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0014] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any combination thereof.

[0015] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. These benefits and / or advantages may be obtained individually by the various embodiments and features of the specification and drawings, although not all of these features need be present to obtain one or more of such benefits and / or advantages. [Brief explanation of the drawings]

[0016] [Figure 1] 1 shows a schematic diagram of an example architecture of a 3GPP NR system. [Figure 2] 1 illustrates a block diagram of an example user plane and control plane architecture for an LTE eNB, an NR gNB, and a UE. [Figure 3] Schematic diagram showing usage scenarios for Massive Machine-Type Communication (mMTC) and Ultra-Reliable Low-Latency Communication (URLLC). [Figure 4] 1 illustrates a communication system in NR, including a user equipment (UE) and a base station (BS), according to an exemplary scenario. [Figure 5] 1 illustrates a block diagram of an example implementation of a user equipment (UE) and a base station (BS). [Figure 6] 1 illustrates a block diagram of an example implementation of a user equipment (UE) and a base station (BS). [Figure 7] 1 illustrates a sequence diagram of a user equipment performing multiple PUSCH transmissions according to an exemplary mechanism. [Figure 8] 1 shows a schematic diagram of a table configured by RRC for multiple PUSCH transmissions and corresponding time domain resource allocation for multiple PUSCH transmissions. [Figure 9] 1 shows a schematic diagram of a table configured by RRC for multiple PUSCH transmissions and corresponding time domain resource allocation for multiple PUSCH transmissions. [Figure 10] 1 illustrates a block diagram of another exemplary implementation of a user equipment (UE) and another exemplary implementation of a base station (BS). [Figure 11] 1 illustrates a block diagram of another exemplary implementation of a user equipment (UE) and another exemplary implementation of a base station (BS). [Figure 12] 1 illustrates a sequence diagram of a user equipment performing PUSCH repetition according to an exemplary mechanism. [Figure 13] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain using a sixth exemplary implementation; [Figure 14] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain using a sixth exemplary implementation; [Figure 15] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to another use of the sixth exemplary implementation form; [Figure 16] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to another use of the sixth exemplary implementation form; [Figure 17] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to a further use of a sixth exemplary implementation form; [Figure 18] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to a further use of a sixth exemplary implementation form; [Figure 19] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to the use of the seventh exemplary implementation form; [Figure 20] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to the use of the seventh exemplary implementation form; [Figure 21] 13 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to another use of the seventh exemplary implementation form; [Figure 22] 13 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to another use of the seventh exemplary implementation form; [Figure 23] 13 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to the use of an eighth exemplary implementation form; [Figure 24] 13 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to the use of an eighth exemplary implementation form; [Figure 25] 13 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to another use of the eighth exemplary implementation form; [Figure 26]13 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain according to another use of the eighth exemplary implementation form; [Figure 27] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain using the ninth exemplary implementation form. [Figure 28] 10 shows a schematic diagram of a table configured by RRC for PUSCH repetition and corresponding resource allocation in the time domain using the ninth exemplary implementation form. DETAILED DESCRIPTION OF THE INVENTION

[0017] Exemplary embodiments are described in more detail below with reference to the accompanying drawings.

[0018] As discussed in the Background section, 3GPP is formulating the next release of fifth-generation cellular technology (referred to briefly as 5G), which includes the development of New Radio (NR) access technology operating in the frequency range up to 100 GHz. 3GPP must identify and develop the technology elements necessary for successful standardization of NR systems, meeting both immediate market needs and longer-term requirements in a timely manner. To achieve this, the study item "New Radio Access Technology" is considering evolving and developing the radio interface and radio network architecture. Results and agreements are summarized in Non-Patent Document 1, which is incorporated herein by reference in its entirety.

[0019] In particular, a tentative agreement was reached on the overall system architecture. The NG-RAN (Next Generation - Radio Access Network) consists of gNBs, which terminate the Next Generation (NG) radio access user plane protocols SDAP / PDCP / RLC / MAC / PHY (Service Data Application Protocol / Packet Data Convergence Protocol / Radio Link Control / Medium Access Control / Physical) and the control plane protocol RRC (Radio Resource Control) towards the UEs. The NG-RAN architecture is shown in Figure 1, based on Section 4 of 3GPP TS 2013-01-01226, which is incorporated herein by reference. The gNBs are interconnected with each other by Xn interfaces. The gNBs are also connected to the Next Generation Core (NGC) by NG interfaces, and more specifically to the Access and Mobility Management Function (AMF) (e.g., a specific core entity running the AMF) by NG-C interfaces and to the User Plane Function (UPF) (e.g., a specific core entity running the UPF) by NG-U interfaces.

[0020] A variety of different deployment scenarios are currently being considered for support, as reflected, for example, in Non-Patent Document 3. This document presents, for example, a decentralized deployment scenario (Section 5.2 of Non-Patent Document 3) (a centralized deployment is shown in Section 5.4, which is incorporated herein by reference), in which base stations supporting 5G NR can be deployed. Figure 2 illustrates an exemplary decentralized deployment scenario, which is based on Figure 5.2.-1 of Non-Patent Document 3, but further illustrates an LTE eNB and user equipment (UE), where the user equipment (UE) is connected to both the gNB and the LTE eNB. As mentioned previously, the new eNB in NR 5G can be exemplarily referred to as a gNB.

[0021] As previously mentioned, the 3rd Generation Partnership Project New Radio (3GPP NR) is considering three use cases that are envisioned to support a wide variety of services and applications with IMT-2020 (see Non-Patent Document 4). Phase 1 specifications for enhanced mobile broadband (eMBB) were finalized by 3GPP in December 2017. Current and future work will include standardization of ultra-reliable and low-latency communications (URLLC) and large-scale machine-type communications, in addition to further extending support for eMBB. Figure 3 (from Non-Patent Document 4) shows some examples of envisioned usage scenarios for IMT-2020 and beyond.

[0022] URLLC use cases have stringent requirements for capabilities such as throughput, latency, and availability, and are envisioned as one of the means to realize future vertical applications, such as wireless control of industrial manufacturing and production processes, remote medical surgery, power distribution automation in smart grids, and transportation safety. The current Work Item Description (WID) [5] has agreed to support ultra-high reliability for URLLC by identifying technologies to meet the requirements set by [6]. Key requirements for NR URLLC in Release 15 include target user plane latency of 0.5 ms for the uplink (UL) and 0.5 ms for the downlink (DL). Typical URLLC requirements for a single packet transmission are a block error rate (BLER) of 1E-5 for a 32-byte packet size with a user plane latency of 1 ms.

[0023] From the perspective of RAN1, reliability can be improved in several possible ways. The current scope for improving reliability is described in Non-Patent Document 7 and includes defining a separate CQI table for URLLC, a more compact DCI format, and PDCCH repetition. However, as NR becomes more stable and development progresses, the scope for achieving ultra-high reliability may expand (see also Non-Patent Document 6, which is incorporated herein by reference, for key requirements for NR URLLC). Therefore, NR URLLC in Release 15 must be able to transmit 32-byte data packets within 1 ms user plane latency with a success probability corresponding to a BLER of 1E-5. Specific use cases for NR URLLC in Release 15 include augmented reality / virtual reality (AR / VR), e-health, e-safety, and mission-critical applications (see also Non-Patent Document 4).

[0024] Furthermore, the technical enhancements targeted for NR URLLC in Release 15 are targeted at improving latency and increasing reliability. The technical enhancements for improving latency include configurable numerology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level repetition of data channels, and downlink preemption. Preemption means that a transmission for which resources have already been allocated is stopped and the already allocated resources are used for another transmission requested later with smaller latency / higher priority requirements. Thus, an already granted transmission is preempted by a later transmission. Preemption applies regardless of the specific service type. For example, a transmission of service type A (URLLC) can be preempted by a transmission of service type B (e.g., eMBB). Reliability-related enhancements include dedicated CQI / MCS tables for a target BLER of 1E-5 (see also Non-Patent Document 8, Non-Patent Document 9, Non-Patent Document 10, Non-Patent Document 11, all of which are incorporated herein by reference for technical enhancements).

[0025] The mMTC use case is characterized by a very large number of connected devices transmitting relatively small amounts of data that are generally latency sensitive. The devices need to be low cost and have extremely long battery life. From an NR perspective, utilizing very narrow bandwidth portions is one possible solution to achieve power savings from the UE perspective, enabling long battery life.

[0026] As mentioned above, it is expected that the range of reliability in NR will expand. One key requirement for all cases, especially for URLLC and mMTC, is high or ultra-high reliability. Several mechanisms can be considered to improve reliability from a radio perspective and a network perspective. In general, there are several key areas that can help improve reliability. These areas include compact control channel information, data channel / control channel repetition, and diversity related to the frequency, time, and / or spatial domains. These areas are generally applicable to reliability, regardless of the specific communication scenario.

[0027] NR URLLC Release 16 recognizes additional use cases with more stringent requirements, such as factory automation, the transportation industry, and power supply (see Non-Patent Document 12, which is incorporated herein by reference). The more stringent requirements include higher reliability (up to 10 -6 level), higher availability, packet sizes up to 256 bytes, time synchronization on the order of a few μs (values between 1 μs and a few μs depending on the frequency range), and low latency on the order of 0.5-1 ms (especially a target latency of 0.5 ms for the user plane) (see also Non-Patent Document 13 and Non-Patent Document 12, which are incorporated herein by reference).

[0028] Furthermore, Release 16 NR URLLC recognizes several technology enhancements from a RAN1 perspective. In particular, PDCCH enhancements related to compact DCI, PDCCH (Physical Downlink Control Channel) repetition, and increased PDCCH monitoring. Furthermore, UCI (Uplink Control Information) enhancements related to HARQ (Hybrid Automatic Repeat Request) enhancements and CSI feedback enhancements. PUSCH enhancements related to minislot-level hopping and retransmission / repetition are also recognized. The term "minislot" refers to a transmission time interval (TTI) containing fewer symbols than a slot (a slot with 14 symbols).

[0029] Generally, the TTI determines the timing granularity of scheduling assignments. One TTI is the time interval over which a given signal is mapped to the physical layer. Traditionally, the TTI length can vary from 14 symbols (slot-based scheduling) to 2 symbols (non-slot-based scheduling). Downlink and uplink transmissions are specified to be organized into frames (10 ms duration) consisting of 10 subframes (1 ms duration). In slot-based transmissions, a subframe is divided into multiple slots, the number of slots being defined by the numerology / subcarrier spacing, with specified values ranging from 10 slots for a 15 kHz subcarrier spacing to 320 slots for a 240 kHz subcarrier spacing. The number of OFDM symbols per slot is 14 for normal cyclic prefix and 12 for extended cyclic prefix (see 3GPP TS 2.0, 2013-01-10, Sections 4.1 (General Frame Structure), 4.2 (Numerology), 4.3.1 (Frames and Subframes), and 4.3.2 (Slots) of 3GPP TS 2.0, which is incorporated herein by reference). However, the allocation of time resources for transmission may also be non-slot-based. In particular, a TTI in a non-slot-based allocation may correspond to a minislot instead of a slot. For example, one or more minislots may be allocated to the requested transmission of data / control signaling. In a non-slot-based allocation, the minimum length of a TTI may conventionally be two OFDM symbols.

[0030] Other recognized enhancements relate to scheduling / HARQ / CSI processing timelines and prioritization / multiplexing of uplink transmissions between UEs. Further recognized enhancements focus on improved configured grant behavior, such as uplink configured grant (grant-free) transmissions, exemplary methods such as explicit HARQ-ACK ensuring K repetitions and minislot repetition within a slot, and other enhancements related to MIMO (multiple input multiple output) (see also Non-Patent Document 13).

[0031] This disclosure relates to possible Layer 1 enhancements aimed at further improving reliability / latency and other requirements related to the use cases identified in 3GPP TS 26.110.12 ...

[0032] [PUSCH REPEAT] One scope for possible enhancements relates to minislot repetition of PUSCH within a slot. Below we explain the motivation for supporting PUSCH repetition within a slot, which may enable extensions of the repetition mechanism to further improve reliability and / or latency in order to meet the new requirements of NR URLLC.

[0033] To achieve the latency requirements for URLLC PUSCH transmission, a one-shot transmission (i.e., one TTI allocation) is ideal if the reliability requirements are met. However, a single transmission does not always achieve the target BLER of 1E-6. Therefore, a retransmission or repeat mechanism is required.

[0034] In NR Release 15, both retransmission and repetition are supported to achieve the target BLER when one-shot transmission is not sufficient. HARQ-based retransmission is well known and improves overall reliability by using feedback information to refine subsequent retransmissions according to channel conditions. However, HARQ-based retransmissions incur additional delays due to the feedback processing timeline. Therefore, repetition is useful for delay-sensitive services because it allows subsequent transmissions of the same transport block without waiting for feedback.

[0035] PUSCH repetition can be defined as "transmitting the same transport block two or more times without waiting for feedback of the previous transmission(s) of the same transport block." The advantage of PUSCH retransmission is an overall increase in reliability and a reduction in latency compared to HARQ since no feedback is required. However, in general, link adaptation is not possible and resource utilization may be inefficient.

[0036] NR Release 15 introduces limited support for repetition. Only semi-static configuration of repetition is allowed. Furthermore, repetition is only allowed between slots (slot-level PUSCH repetition). Repetition is only possible in slots following the slot of the previous transmission. In the case of repetition between slots, the latency between repetitions may be too long depending on the numerology and service type (e.g., URLLC, eMBB).

[0037] This limited support for repetition is primarily useful for PUSCH mapping type A, which only allows PUSCH transmissions starting at the beginning of a slot. When repetition is used, the first PUSCH transmission and each repetition starts at the beginning of multiple consecutive slots.

[0038] The limited support for repetition is less useful for PUSCH mapping type B, which allows PUSCH transmissions to start at any symbol within a slot. If repetition is used, the initial PUSCH transmission and each repetition start at the same symbol within multiple consecutive slots.

[0039] In either case, such limited support may not be able to meet the stringent latency requirements of NR Release 15 (i.e., a maximum latency of 0.5 ms), which is why minislot repetition is necessary. In addition, limited support for repetition negates the benefit gained from minislots, i.e., a transmission time interval (TTI) containing fewer symbols than a slot (a slot contains 14 symbols).

[0040] [PUSCH allocation] Another scope of potential enhancements relates to minislot allocation of PUSCH within a slot. Below, we explain the motivation for supporting allocation of multiple different PUSCH transmissions within a slot, which could enable potential extension of uplink usage to further improve latency while meeting reliability requirements to further meet the new requirements of NR URLLC.

[0041] To achieve the latency requirements for URLLC PUSCH transmission, one-shot transmission (i.e., single TTI allocation) is ideal, again if reliability is met. However, in the case of simultaneous PUSCH transmissions, the user plane target latency of 0.5 ms is not always achieved. Therefore, an extension of the uplink allocation is required.

[0042] In NR Release 15, uplink scheduling is constrained to one uplink grant per TTI. For a single PUSCH transmission, this scheduling constraint is not a limitation, and the user plane target latency can be achieved through one-shot transmission. However, for simultaneous PUSCH transmissions, this scheduling constraint results in one-shot transmissions not being sufficient to meet the user plane target latency.

[0043] In particular, simultaneous PUSCH transmissions require separate uplink grants, which must be signaled in consecutive TTIs due to scheduling constraints. Therefore, for simultaneous PUSCH transmissions, the scheduling constraints introduce unnecessary delays. It is also not possible to allocate PUSCHs to multiple minislots within a slot.

[0044] In either case, these scheduling constraints may make it impossible to achieve the stringent latency requirements of NR Release 15 (i.e., a maximum latency of 0.5 ms). This necessitates minislot allocation for PUSCH. In addition, limited support for repetition negates the benefit of minislots, i.e., a transmission time interval (TTI) containing fewer symbols than a slot (a slot contains 14 symbols).

[0045] [Common uplink scenarios] In view of the above, the authors of the present disclosure have recognized that there is a need for more flexible support of PUSCH transmissions (ie, a mechanism that is not constrained to PUSCH transmissions requiring a separate uplink grant).

[0046] At the same time, the increased flexibility does not come at the cost of additional signaling overhead. In other words, the authors of the present disclosure have recognized that flexible support for PUSCH transmissions shall not require changes to the current uplink scheduling mechanism (i.e., the current format of the uplink grant). In other words, the signaling mechanism for conveying the uplink grant, for example in the form of downlink control information (DCI) format 0-0 or 0-1, remains the same, thus avoiding additional signaling overhead when scheduling PUSCH transmissions.

[0047] Therefore, the proposal of this disclosure is to support flexible timing of transport block (TB) transmissions without necessarily incurring additional signaling overhead. The following disclosure is presented with a focus on uplink transmissions. However, this should not be construed as a limitation, as the concepts disclosed herein are equally applicable to downlink transmissions.

[0048] 4 illustrates an exemplary communication system including a user equipment (UE) 410 and a base station (BS) 460 in a wireless communication network. Such a communication system may be a 3GPP system, such as NR and / or LTE and / or UMTS. For example, as illustrated, the base station (BS) may be a gNB (gNodeB, e.g., an NR gNB) or an eNB (eNodeB, e.g., an LTE gNB). However, the present disclosure is not limited to these 3GPP systems or any other systems.

[0049] Although the embodiments and example implementations are described using some terminology of a 3GPP system, the present disclosure is also applicable to any other communication system, in particular any cellular, wireless, and / or mobile system.

[0050] It should be noted that numerous assumptions have been made to clearly and easily explain the principles underlying this disclosure. However, it should be understood that these assumptions are merely examples for illustrative purposes and do not limit the scope of this disclosure. Those skilled in the art will recognize that the principles of the following disclosure can be applied in a variety of scenarios, as set forth in the claims, and in ways not explicitly described herein.

[0051] In LTE and NR, a mobile terminal is referred to as user equipment (UE). User equipment can be a mobile device such as a mobile phone, a smartphone, a tablet computer, or a USB (Universal Serial Bus) stick with user equipment functionality. However, the term mobile device is not limited thereto, and in general, a repeater can have the functionality of such a mobile device, or a mobile device can function as a repeater.

[0052] A base station (BS) forms at least part of a system of interconnected units (e.g. a (central) baseband unit and various radio frequency units) and interfaces with the various antenna panels and radio heads in the network to serve the terminals. In other words, the base station provides wireless access to the terminals.

[0053] Referring again to the figure, the user equipment 410 includes a processing circuit (or processor) 430 and a transmitter / receiver (or transceiver) 420, which are shown as separate building blocks in the figure. Similarly, the base station 460 includes a processing circuit (or processor) 480 and a transmitter / receiver (or transceiver) 470, which are shown as separate building blocks in the figure. The transmitter / receiver 420 of the user equipment 410 is communicatively coupled to the transmitter / receiver 470 of the base station 460 via a wireless link 450.

[0054] [First common uplink scenario] 5 and 6 respectively depict exemplary implementations according to a first general scenario of the building blocks of a user equipment 410 and a base station 460. The user equipment 410 of this exemplary implementation includes a PUSCH config IE receiver 520-a, a table configuration processing circuit 530-a, a DCI receiver 520-b, a configured grant config IE receiver 520-c, an allocated resource determination processing circuit 530-b, a transport block selection transmitter 520-d, a PUSCH transmission generation transmitter 520-e, and a PUSCH transmitter 520-f.

[0055] Similarly, the base station 460 of this exemplary implementation includes a PUSCH config IE transmitter 670-a, a table configuration processing circuit 580-a, a DCI transmitter 570-b, a configured grant config IE transmitter 570-c, a resource allocation processing circuit 580-b, and a PUSCH receiver 570-d.

[0056] In general, this disclosure assumes that user equipment 410 is within communication range of base station 460 and is configured to use at least one bandwidth portion on the downlink and at least one bandwidth portion on the uplink, which are located within the carrier bandwidth served by base station 460.

[0057] Furthermore, this disclosure assumes that the user equipment 410 is operating in a radio resource control (RRC) connected state (referred to as RRC_CONNECTED) and is therefore capable of receiving data and / or control signals from the base station 460 on the downlink and transmitting data and / or control signals to the base station 460 on the uplink.

[0058] Before performing multiple PUSCH transmissions as proposed in this disclosure, the user equipment 410 receives control messages defined in the radio resource control (RRC) protocol layer and the medium access control (MAC) protocol layer, i.e., employs signaling mechanisms that are readily available in different protocol layers of various communication technologies.

[0059] In general, there is a substantial difference between the control messages defined in RRC and those defined in MAC. This difference is already apparent since RRC control messages are typically used to semi-statically configure radio resources (e.g., radio links), while MAC control messages are used to dynamically define each medium access (e.g., transmission) individually. From this point of view, it can be immediately seen that RRC control occurs less frequently than MAC control.

[0060] Therefore, RRC control messages have been tolerated in standardization, whereas excessive MAC control signaling overhead can substantially degrade the performance of a communication system, or in other words, MAC control signaling overhead is generally recognized as a constraint on system performance.

[0061] In view of the above, the authors of the present disclosure propose a mechanism that overcomes the drawbacks of conventional mechanisms and allows flexible transport block (TB) transmission in uplink or downlink while avoiding MAC signaling overhead.

[0062] In the context of this disclosure, the term "transport block" should be understood as a data unit for uplink and / or downlink transmission. For example, the term "transport block" is widely understood to be equivalent to a packet data unit (PDU) at the MAC layer. Thus, a transport block transmission is equally understood as a physical uplink shared channel (PUSCH) transmission and / or a physical downlink shared channel (PDSCH) transmission.

[0063] In particular, because PUSCH and / or PDSCH transmissions typically carry a payload, this disclosure refers to PUSCH and / or PDSCH transmissions carrying a MAC PDU. In other words, the term "PUSCH and / or PDSCH transmission" should be understood to describe transmitting a MAC PDU on a PUSCH and / or PDSCH.

[0064] Referring to FIG. 7, a general scenario related to performing multiple PUSCH transmissions based on a dynamic grant, i.e., a DCI carrying a time domain resource allocation field (e.g., a DCI of DCI format 0-0 or a DCI of DCI format 0-1), will be described.

[0065] However, this description should not be construed as limiting the present disclosure to only extending PUSCH transmissions (e.g., repeating PUSCH transmissions), as it will become apparent that the concepts disclosed herein are equally applicable to downlink transmissions.

[0066] The receiver 420 of the user equipment 410 receives a physical uplink shared channel (PUSCH) config information element (IE) (see, e.g., step 710 of FIG. 7). This PUSCH config IE is received in the form of radio resource control (RRC) signaling and is applicable to a particular bandwidth portion. The PUSCH config IE is received from the base station 460 serving that particular bandwidth portion. This receiving operation can be performed, for example, by the PUSCH config IE receiver 520-a of FIG. 5.

[0067] The PUSCH config IE conveys a list of parameters in the form of an information element (IE) called "PUSCH-TimeDomainResourceAllocationList," in particular, and each parameter in this parameter list is called a "PUSCH-TimeDomainResourceAllocation."

[0068] The processor 430 of the user equipment 410 then configures a table defined by the PUSCH Time Domain Resource Allocation List IE conveyed in the received PUSCH config IE (see, e.g., step 720 of FIG. 7 ). The configured table includes at least one row that includes a first set of values associated with time domain resources that are allocated for the multiple PUSCH transmissions.

[0069] For example, the table may include rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator. This configuration operation may be performed, for example, by table configuration processing circuit 530-a of FIG. 5.

[0070] In one example implementation, each row of the table configured by the RRC corresponds to one of a number of parameters called "PUSCH-TimeDomainResourceAllocation" in a parameter list called "PUSCH-TimeDomainResourceAllocationList", however, this should not be understood as a limitation to the present disclosure, as will be evident from the following alternative scenario.

[0071] Scenarios different from this exemplary implementation are also possible, in which some rows of the configured table correspond to respective parameters contained in the IE with parameter list, and other rows are configured according to a pre-specified set of rules that directly apply the principles laid out in the PUSCH Time Domain Resource Allocation List IE.

[0072] However, even in these scenarios, the entire table configured by the RRC is still defined by the PUSCH Time Domain Resource Allocation List IE.

[0073] The receiver 420 of the user equipment 410 then receives downlink control information (DCI) signaling (see, e.g., step 730 of FIG. 7). This DCI conveys a time domain resource allocation field with value m, which provides row index m+1 in the configured table. This receiving operation can be performed, for example, by the DCI receiver 520-b of FIG. 5.

[0074] In the context of the present disclosure, this DCI conveys an uplink grant because it serves the purpose of triggering a PUSCH transmission. In this regard, the received DCI is DCI format 0-0 or DCI format 0-1. Also, the described scenario refers to a situation where PUSCH recurrences are scheduled by a dynamic grant.

[0075] However, this should not be understood as a limitation on the present disclosure, as the concepts disclosed herein are equally applicable to configured grant or grant-free scheduling techniques, a detailed description of which is provided as an alternative to the mechanism depicted in FIG.

[0076] The processor 430 of the user equipment 410 then determines the resources allocated for the multiple PUSCH transmissions. For clarity and brevity, the following description focuses on the allocation of time-domain resources. This determination operation may be performed, for example, by the allocated resource determination processing circuit 530-b of FIG. 5.

[0077] The time domain resources used by the user equipment 410 for the multiple PUSCH transmissions have been previously allocated by the base station 460. Thus, in this context, the processor 430 determines which of the previously allocated resources to use for the multiple PUSCH transmissions. For ease of reference, multiple PUSCH transmissions may be understood to include a first PUSCH transmission and at least one subsequent PUSCH transmission, all scheduled by one DCI.

[0078] As part of this determination operation, processor 430 determines a time domain resource to be allocated for a first of the multiple PUSCH transmissions based on (i) the index of the slot carrying the received DCI and (ii) a first set of values included in an indexed row of a table configured by the RRC that is associated with the time domain resource to be allocated (see e.g., step 740 of FIG. 7).

[0079] For example, processor 430 may determine the time domain resources allocated for the first PUSCH transmission based on (i) the index of the slot carrying the received DCI, (ii) a value K2 indicating a slot offset contained in the indexed row of a table configured by the RRC, and (iii) a value SLIV indicating a start-length indicator, which means that processor 430 previously determined that the value indicating the PUSCH mapping type indicates Type B mapping (the decision based on the value SLIV only needs to be made when PUSCH transmission is allowed to start at any symbol within the slot).

[0080] Continuing with this example, assume that the received DCI is conveyed in slot number k and has a time-domain resource allocation field with value m. In this case, the processor returns to the row with row index m+1 of the table configured by the RRC for the first PUSCH transmission and uses the slot offset value K2 and the start-length indicator value SLIV. Using these values, the processor determines that the time-domain resource allocated for the first PUSCH transmission is contained in slot number k+K2 and has a starting position and length in this slot, in symbols, that correspond to the SLIV value.

[0081] In this example, processor 430 may also use a value indicating a PUSCH mapping type, which is further included in the first set of values, when determining the allocated resources. Specifically, if this value indicates a PUSCH mapping of type A, processor 430 uses only the length of the value SLIV indicating the start and length indicator. If the value indicates a PUSCH mapping of type B, processor 430 uses both the start and length of the value SLIV indicating the start and length indicator.

[0082] Processor 430 then proceeds to operate on the subsequent PUSCH transmission.

[0083] To this end, the processor 430 checks a second parameter (see, e.g., step 750 of FIG. 7) that indicates to the user equipment 410 whether the subsequent PUSCH transmission is a different (or individual) PUSCH transmission or a repeated PUSCH transmission. In other words, the second parameter instructs the processor 430 how the subsequent PUSCH transmission is to be utilized (i.e., to carry a different transport block or to carry the same transport block).

[0084] 7, it should be understood that the first transmission of the multiple PUSCH transmissions is always a unique PUSCH transmission, e.g., a different (or individual) PUSCH transmission. Thus, the second parameter specifies only whether a subsequent PUSCH transmission is different (or not different) from this first (or other preceding) PUSCH transmission. In this regard, the processor 430 may perform a check of the second parameter after completing operations for the first PUSCH transmission.

[0085] It should be emphasized here that the second parameter is included in a row of the RRC configured table that is defined by the PUSCH Time Domain Resource Allocation List IE, in other words, since the RRC configured table (as a whole) is defined by the PUSCH Time Domain Resource Allocation List IE, the second parameter included in this table is also defined by the PUSCH Time Domain Resource Allocation List IE.

[0086] However, this should not be understood as a limitation of the present disclosure, as the concepts disclosed herein are equally applicable to a second parameter that uniformly specifies the differentiation (or non-differentiation) of all of the multiple PUSCH transmissions (i.e., whether all PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions), in which case different sequences of operations by processor 430 are also possible.

[0087] According to one example implementation, as will be explained in more detail below, the processor 430 may return to the row with row index m+1 of the RRC configured table and check whether the row includes the second parameter to check the second parameter. However, according to another example implementation, the processor 430 may also use the received DCI or physical layer configuration to check whether the second parameter indicates a different or repeated PUSCH transmission.

[0088] If the result of the check indicates a different (or separate) PUSCH transmission, the operation sequence of the mechanism depicted in FIG. 7 proceeds with the processor 430 determining the time domain resources to be allocated for a subsequent (non-initial) transmission in the form of a different (or separate) PUSCH transmission (see e.g. step 770 of FIG. 7).

[0089] 7, the processor 430 does not necessarily determine the time domain resources based on explicit indication information signaled from the base station 460 to the user equipment 410. Instead, the processor 430 may rely on a pre-specified (e.g., fixedly defined in a relevant standard) timing relationship between the first and subsequent PUSCH transmissions to determine the time domain resources for different (separate) PUSCH transmissions.

[0090] The processor 430 may also determine the time domain resource by applying the same timing relationship specified in the first set of values to consecutive slots for subsequent PUSCH transmissions. As a result, the first PUSCH transmission and each subsequent PUSCH transmission start from the same symbol in consecutive slots and have the same symbol length. However, as will be apparent from alternative embodiments below, this should not be understood as a limitation of the present disclosure.

[0091] If the result of the check indicates a repeated PUSCH transmission, the operational sequence of the mechanism depicted in FIG. 7 proceeds to the step (see e.g. step 755 of FIG. 7) in which processor 430 checks whether there is an (explicit) time domain resource allocation for a subsequent PUSCH transmission in the form of a repeated transmission of the first (or other preceding) PUSCH transmission.

[0092] To this end, processor 430 checks whether there is a third set of values associated with an (explicit) time domain resource allocation for a subsequent PUSCH transmission (see e.g. step 755 of FIG. 7 ). To this end, processor 430 returns to the row with row index m+1 and checks whether the row comprises a third set of values (e.g. at least one value) specifying time domain resources to be allocated for a subsequent PUSCH transmission in the form of a repeated PUSCH transmission.

[0093] If the check results in "no," processor 430 uses a conventional slot-based repetition mechanism (if configured) for repetitions of the initial PUSCH transmission (see, e.g., step 760 of FIG. 7). In other words, processor 430 relies on a pre-specified (e.g., fixedly defined in the relevant standard) timing relationship between the initial PUSCH transmission and its repetitions. For example, this can result in the initial PUSCH transmission and each repetition starting from the same symbol of multiple consecutive slots and having the same symbol length.

[0094] Referring again to the present example, the processor 430 returns to the row with row index m+1 of the table configured by the RRC for at least one subsequent PUSCH transmission and determines that the resources allocated for the first repetition of the initial PUSCH transmission are contained in slot number k+K2+1 (1 is a predefined constant fixed by standardization) and have a starting position and length in that slot, in symbols, corresponding to the same value SLIV.

[0095] If a second repetition is present, the processor 430 determines that the resources allocated for the second repetition of the initial PUSCH transmission are contained in slot number k+K2+2 (where 2 is again a predefined constant fixed by standardization) and have a starting position and length in that slot, in symbols, corresponding to the same value SLIV as the initial PUSCH transmission and its first repetition.

[0096] Further assuming in this example that the PUSCH mapping type indicated in the row with row index m+1 is Type B, and that the value SLIV indicates a symbol length of 4 starting at symbol 4, processor 430 determines that the initial PUSCH transmission, its first repetition, and its second repetition each have resources corresponding to symbol 4, symbol 5, symbol 6, and symbol 7 in slots numbered k+K2, k+K2+1, and k+K2+2, respectively.

[0097] Obviously, these allocated resources determined by the processor 430 cannot be flexibly configured. This is overcome by the following alternative determination method by the processor 430.

[0098] If the check results in "YES", the processor 430 uses a third set of values (e.g., at least one value) included in the indexed row of the table configured by the RRC to determine the resources allocated for the repetition of the initial PUSCH transmission in the subsequent PUSCH transmission (see, e.g., step 770 of FIG. 7). In other words, the included third set of values specifies the time domain resources allocated for the repetition of the initial PUSCH transmission.

[0099] It should be emphasized here that the third set of values (e.g., at least one value) is included in a row of the RRC-configured table defined by the PUSCH Time Domain Resource Allocation List IE, in other words, since the RRC-configured table (as a whole) is defined by the PUSCH Time Domain Resource Allocation List IE, the third set of values included in this table is also defined by the PUSCH Time Domain Resource Allocation List IE.

[0100] To meet this constraint, the third set of values may be specified (directly) by parameters contained in the PUSCH Time Domain Resource Allocation List IE, or alternatively, the third set of values may be inferred (indirectly) from relevant parameters contained in the PUSCH Time Domain Resource Allocation List IE. In either case, the third set of values specifies the repetition of the initial PUSCH transmission in the time domain.

[0101] In an exemplary implementation, the processor 430 can (indirectly) infer a value SLIV′ indicating another start-length indicator for the third value set from a modified SLIV parameter included in the PUSCH time domain resource allocation list IE, e.g., provided with twice, three times, ... more bits (e.g., 14 bits instead of 7 bits, or 21 bits instead of 7 bits, etc.). Thus, when configuring the table, the processor 430 can (indirectly) infer the value SLIV included in the first value set of the table configured by the RRC and the value SLIV′ included in the third value set using this modified SLIV parameter.

[0102] It is important to note that the processor 430 of the user equipment 410 determines the time domain resources allocated for the repetition of the initial PUSCH transmission using a third set of values from the indexed row of the table configured by the RRC, which is substantially different from conventional slot-based repetition mechanisms.

[0103] 7, the processor 430 may also determine the time domain resources allocated for a subsequent PUSCH transmission in the form of a different (or separate) PUSCH transmission using a third set of values from an indexed row of the table configured by the RRC, whereby the third set of values is not restricted to being used for repeated PUSCH transmissions.

[0104] In this alternative mechanism, after the result of checking the second parameter (see, e.g., step 750 of FIG. 7 ) indicates a different (or separate) PUSCH transmission, the processor 430 deviates from the mechanism depicted in FIG. 7 , i.e., checks whether there is a third set of values associated with (explicit) time domain resource allocation (e.g., similar to step 755 of FIG. 7 ).

[0105] When performing this check, the mechanism differs from the mechanism depicted in Figure 7. This difference applies only if a different (or separate) PUSCH transmission is indicated. If the result of this check is "yes", the processor 430 determines the time domain resources allocated for the subsequent PUSCH transmission in the form of a different (or separate) PUSCH transmission using a third set of values.

[0106] This method differs from conventional mechanisms for the following reasons.

[0107] First, the third set of values is obtained from the row of the table configured by the RRC that is (actively) indexed by row index m+1, which is derived from the value m in the time domain resource allocation field of the received DCI. In this respect, by varying the index value m in the time domain resource allocation field of the received DCI, it is possible to vary the third set of values used to determine the time domain resources allocated for a subsequent PUSCH transmission, thus increasing the flexibility of the resources allocated in this way.

[0108] Second, the third set of values is obtained from the (same) row of the table configured by the RRC that is (already) indexed by row index m+1, which is derived from value m in the time-domain resource allocation field of the received DCI. In this respect, no additional index value other than index value m in the time-domain resource allocation field of the received DCI is needed when determining the resources to be allocated for a subsequent PUSCH transmission. Thus, additional signaling overhead is avoided.

[0109] As a result, this allows for increased flexibility while avoiding signaling overhead, i.e. the processor 430 of the user equipment 410 determines the resources allocated for repetition using a third set of values from the indexed row of the table configured by the RRC.

[0110] The transmitter 420 of the user equipment 410 then selects a transport block of data to be conveyed in the multiple PUSCH transmissions, including the first PUSCH transmission and the subsequent PUSCH transmissions (see, e.g., step 780 of FIG. 7), where this selection of the transport block of data is based on a second parameter.

[0111] If the second parameter indicates different (or separate) PUSCH transmissions, the transmitter 420 selects a different transport block of data for each of the multiple PUSCH transmissions. If the second parameter indicates repeated PUSCH transmissions, the transmitter 420 selects the same transport block of data for all of the multiple PUSCH transmissions. This selection operation can be performed, for example, by transport block selection transmitter 520-d of FIG. 5.

[0112] Transmitter 420 then generates a plurality of PUSCH transmissions carrying the selected transport blocks of data (see, e.g., step 790 of FIG. 7). This generating operation may be performed, for example, by PUSCH transmission generating transmitter 520-e of FIG. 5.

[0113] In example implementations, the generating operation can be based on at least one fourth value associated with generating multiple PUSCHs in an indexed row of an RRC-configured table, as described in more detail below. Additionally, the generating operation can be according to at least one fifth parameter associated with generating multiple PUSCH transmissions in an indexed row of an RRC-configured table, as also described in more detail below.

[0114] Finally, the transmitter 420 of the user equipment 410 transmits the PUSCH transmission (not shown in FIG. 7) using the allocated resources determined for the initial PUSCH transmission and the subsequent PUSCH transmissions (i.e., the subsequent PUSCH transmissions in the form of different (or separate) PUSCH transmissions or repeated PUSCH transmissions), respectively. This transmission operation may be performed, for example, by the PUSCH transmitter 520-f of FIG. 5.

[0115] In summary, a mechanism is disclosed that facilitates the relaxation of uplink scheduling constraints as a result of one uplink grant per TTI. To this end, a table configured by the RRC allows a user equipment to transmit multiple PUSCH transmissions (in the form of different (or individual) PUSCH transmissions or repeated PUSCH transmissions) despite having received only one DCI containing an uplink grant.

[0116] The present disclosure therefore allows for more flexible support of PUSCH transmissions, ie, a mechanism that is not restricted to individual PUSCH transmissions requiring individual uplink grants in consecutive TTIs.

[0117] This mechanism can be combined with possible ways of indicating (explicit) time domain resource allocation for subsequent PUSCH transmissions, as described above. As a result, increased flexibility is facilitated while avoiding signaling overhead, i.e., the processor 430 of the user equipment 410 determines the resources allocated for repetition using a third set of values from the indexed row of a table configured by the RRC.

[0118] The above description is made from the perspective of the user equipment 410. However, this should not be understood as a limitation on the present disclosure. The base station 460 equally performs the general scenarios disclosed herein.

[0119] The transmitter 470 of the base station 460 transmits a Physical Uplink Shared Channel (PUSCH) config information element (IE) in the form of radio resource control (RRC) signaling. This PUSCH config IE is applicable to a specific bandwidth portion. This transmission operation can be performed, for example, by the PUSCH config IE transmitter 670-a of FIG. 6.

[0120] The processor 480 of the base station 460 then configures a table defined by the PUSCH Time Domain Resource Allocation List IE conveyed in the transmitted PUSCH config IE. This RRC-configured table comprises rows, each row having a first set of values associated with time domain resources allocated for multiple PUSCH transmissions. This configuration operation can be performed, for example, by the table configuration processing circuit 680-a of FIG. 6.

[0121] The transmitter 470 of the base station 460 then transmits downlink control information (DCI) signaling conveying a time-domain resource allocation field with value m, which provides row index m+1 in a table configured by the RRC. This transmission operation can be performed, for example, by the DCI transmitter 670-b of FIG. 6.

[0122] The processor 480 of the base station 460 allocates time domain resources for the multiple PUSCH transmissions based on (i) the index of the slot carrying the transmitted DCI and (ii) a first set of values included in the indexed row of the RRC-configured table associated with the allocated time domain resources. This resource allocation operation may be performed, for example, by the resource allocation processing circuit 680-b of FIG. 6.

[0123] Receiver 470 of base station 460 then receives the multiple PUSCH transmissions using each assigned time domain resource, which may be performed by, for example, PUSCH receiver 670-d of FIG.

[0124] Furthermore, receiver 470 of base station 460 processes transport blocks of data carried in the multiple received PUSCH transmissions. This processing operation may be performed by, for example, transport block processing receiver 670-e of FIG. 6.

[0125] In particular, the transport block of data is processed based on at least one second parameter included in an indexed row of a table configured by the RRC, the second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0126] In the following, a general scenario is described that relates to performing PUSCH repetition based on configured grant (or grant-free) (i.e., configured grant config IE received in the form of RRC signaling) and further including a PUSCH time domain resource allocation list IE.

[0127] The receiver 420 of the user equipment 410 receives a physical uplink shared channel (PUSCH) config information element (IE) in the form of radio resource control (RRC) signaling. This PUSCH config IE is applicable to a particular bandwidth portion. The PUSCH config IE is received from the base station 460 that serves that particular bandwidth portion. This receiving operation can be performed, for example, by the PUSCH config IE receiver 520-a of FIG. 5.

[0128] The processor 430 of the user equipment 410 then configures a table defined by the PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE. The table configured by the RRC comprises rows, each row having a first set of values associated with time domain resources allocated for multiple PUSCH transmissions. This configuration operation can be performed, for example, by the table configuration processing circuit 530-a of FIG. 5.

[0129] The receiver 420 of the user equipment 410 then receives in the form of RRC signaling a configured grant config IE conveying a time domain resource allocation field with value m, which provides row index m+1 in the table to be configured. This receiving operation can be performed, for example, by the configured grant config IE receiver 520-c of FIG. 5.

[0130] The processor 430 of the user equipment 410 determines the resources to be allocated for the multiple PUSCH transmissions based on (i) the value of the time-domain offset field that is further conveyed in the received configured grant config IE and associated with the time-domain resource allocation field, and (ii) a first set of values included in an indexed row of the RRC-configured table that is associated with the time-domain resources to be allocated. This determination operation can be performed, for example, by the allocated resource determination processing circuit 530-b of FIG. 5.

[0131] The transmitter 420 of the user equipment 410 then selects a transport block of data to be conveyed in the multiple PUSCH transmissions. This selection operation may be performed, for example, by the transport block selection transmitter 520-d of FIG.

[0132] In particular, the transport block of data is selected based on at least one second parameter included in an indexed row of a table configured by the RRC, the second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0133] Finally, the transmitter 420 of the user equipment 410 transmits a PUSCH transmission using the determined allocated resources, which may be performed by, for example, the PUSCH transmitter 520-f of FIG.

[0134] The above description is made from the perspective of the user equipment 410. However, this should not be understood as a limitation on the present disclosure. The base station 460 equally performs the general scenarios disclosed herein.

[0135] The transmitter 470 of the base station 460 transmits a physical uplink shared channel (PUSCH) config information element (IE) in the form of radio resource control (RRC) signaling, where the PUSCH config IE is applicable to a particular bandwidth portion. This transmission operation can be performed, for example, by the PUSCH config IE transmitter 670-a of FIG. 6.

[0136] The processor 480 of the base station 460 then configures a table defined by the PUSCH Time Domain Resource Allocation List IE conveyed in the transmitted PUSCH config IE. This RRC-configured table comprises rows, each row having a first set of values associated with time domain resources allocated for multiple PUSCH transmissions. This configuration operation can be performed, for example, by the table configuration processing circuit 680-a of FIG. 6.

[0137] The transmitter 470 of the base station 460 then transmits, in the form of RRC signaling, a configured grant config IE conveying a time-domain resource allocation field with value m, which provides row index m+1 in the table configured by the RRC. This transmission operation may be performed, for example, by the configured grant config IE transmitter 670-c of FIG. 6.

[0138] The processor 480 of the base station 460 allocates resources for the multiple PUSCH transmissions based on (i) the value of the time-domain offset field that is further conveyed in the transmitted configured grant config IE and associated with the time-domain resource allocation field, and (ii) a first set of values included in an indexed row of the RRC-configured table that is associated with the allocated time-domain resources. This resource allocation operation can be performed, for example, by the resource allocation processing circuit 680-b of FIG. 6.

[0139] Receiver 470 of base station 460 then receives the multiple PUSCH transmissions using each assigned time domain resource, which may be performed by, for example, PUSCH receiver 670-d of FIG.

[0140] Furthermore, receiver 470 of base station 460 processes transport blocks of data carried in the multiple received PUSCH transmissions. This processing operation may be performed by, for example, transport block processing receiver 670-e of FIG. 6.

[0141] In particular, the transport block of data is processed based on at least one second parameter included in an indexed row of a table configured by the RRC, the second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0142] [Alternatives that complement common scenarios] The above description has focused on implementations in which the base station 460 and / or user equipment 410 assume that the second parameter is included in an indexed row of a table configured by the RRC. However, as previously stated, this description should not be construed as limiting the present disclosure.

[0143] Instead, the above description corresponds to only one of many alternative implementations of the present disclosure that all share the common concept of explicitly or implicitly signaling a second parameter between the base station 460 and the user equipment 410.

[0144] More particularly, the processor 430 of the implementation described above returns to this indexed row of the RRC-configured table in order to determine, for subsequent PUSCH transmissions, whether these transmissions are different (or separate) PUSCH transmissions or repeated PUSCH transmissions from a second parameter included in the row with row index m+1 of the RRC-configured table.

[0145] Those skilled in the art will readily understand that the second parameter is included in a row of an RRC configured table defined by the PUSCH Time Domain Resource Allocation List IE. In other words, since the RRC configured table (as a whole) is defined by the PUSCH Time Domain Resource Allocation List IE, the second parameter included in this table is also defined by the PUSCH Time Domain Resource Allocation List IE.

[0146] In essence, the second parameter in this implementation is explicitly signaled between the user equipment 410 and the base station 460 in the form of a PUSCH time domain resource allocation list IE.

[0147] Alternative implementations of the present disclosure focus on received DCI scheduling a PUSCH transmission (or a PDSCH transmission) that conveys the second parameter to the user equipment 410 and / or base station 460. In such cases, the second parameter can be explicitly or implicitly signaled between the base station 460 and the user equipment 410.

[0148] More particularly, the processor 430 in these alternative implementations returns to the received DCI that schedules multiple PUSCH transmissions for the purpose of determining, for subsequent PUSCH transmissions, from a second parameter conveyed via the received DCI, whether these transmissions are different (or individual) PUSCH transmissions or repeated PUSCH transmissions.

[0149] [First example of alternative implementation] In a first example of an alternative implementation, the second parameter may be conveyed via the received DCI in the form of a separate (e.g., new) bit field included in the DCI transmitted between the base station 460 and the user equipment 410. This method applies equally to DCI in DCI format 0-0 or DCI format 0-1. Thus, this separate (e.g., new) bit field included in the DCI allows the second parameter to be explicitly signaled between the user equipment 410 and the base station 460.

[0150] A separate (e.g., new) bit field included in the DCI may be referred to as, for example, "TBrepeat" and may have a format of only 1 bit indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions. Considering the bit field having a format of 1 bit, a bit value of "0" may indicate that the multiple PUSCH transmissions are transmitted in the form of different (or separate) PUSCH transmissions, whereas a bit value of "1" may indicate that the multiple PUSCH transmissions are used in the form of repeated PUSCH transmissions.

[0151] It should be noted in this context that the DCI received by the receiver 420 of the user equipment 410 uniformly schedules (at least with respect to the timing relationship of the PUSCH transmissions) all of the PUSCH transmissions that are then transmitted by the transmitter 420. Therefore, it may seem unnatural to distinguish between the first and subsequent PUSCH transmissions with respect to a second parameter in a separate (e.g., new) bit field of the DCI.

[0152] To avoid such an artificial distinction, it is assumed that both the DCI and the second parameter contained in the DCI uniformly characterize all of the multiple PUSCH transmissions, although this statement merely simplifies what was stated earlier:

[0153] If the second parameter indicates multiple repeated PUSCH transmissions, it is the subsequent PUSCH transmissions that are repetitions of the first PUSCH transmission. If the second parameter indicates multiple different (or separate) PUSCH transmissions, it is the subsequent PUSCH transmissions that are different from the first PUSCH transmission.

[0154] In summary, this first example of an alternative implementation can achieve a good trade-off between RRC signaling overhead and MAC signaling overhead when transmitting DCI. In addition, this first example facilitates providing a mechanism that does not affect the RRC configuration for time domain resource allocation, since the second parameter is explicitly provided in the DCI.

[0155] [Second example of alternative implementation] In a second example of an alternative implementation, the second parameter may be conveyed via the received DCI in the form of a specific (e.g., new) Radio Network Temporary Identifier (RNTI) used to scramble a cyclic redundancy check (CRC) bit field of the DCI transmitted between the base station 460 and the user equipment 410. This method applies equally to a DCI in DCI format 0-0 or a DCI in DCI format 0-1. Thus, the specific (e.g., new) RNTI allows the second parameter to be implicitly signaled between the user equipment 410 and the base station 460.

[0156] For example, the user equipment 410 may be configured to use a particular (e.g., new) RNTI. After receiving the DCI, the receiver 420 of the user equipment 410 may initially attempt to decode the DCI without scrambling the CRC field of the DCI with the particular (e.g., new) RNTI. If the DCI is successfully decoded by the receiver 420, the processor 430 infers a second parameter that indicates that the DCI schedules all of the multiple PUSCH transmissions in the form of repeated PUSCH transmissions.

[0157] If the receiver 420 fails to initially decode the DCI, it may scramble the CRC field of the DCI with a specific (e.g., new) RNTI and attempt to decode the DCI. If the DCI is successfully decoded by the receiver, the processor 430 infers a second parameter that indicates that the DCI schedules multiple PUSCH transmissions, all in the form of different (or separate) PUSCH transmissions.

[0158] It should again be noted that the DCI received by the receiver 420 of the user equipment 410 uniformly schedules (at least with respect to the timing relationship of the PUSCH transmissions) all of the PUSCH transmissions that are then transmitted by the transmitter 420. Therefore, it may seem unnatural to distinguish between the first and subsequent PUSCH transmissions with respect to a second parameter in a separate (e.g., new) bit field of the DCI.

[0159] To avoid such an artificial distinction, it is assumed that both the DCI and the second parameter contained in the DCI uniformly characterize all of the multiple PUSCH transmissions, although this statement merely simplifies what was stated earlier:

[0160] If the second parameter indicates multiple repeated PUSCH transmissions, it is the subsequent PUSCH transmissions that are repetitions of the first PUSCH transmission. If the second parameter indicates multiple different (or separate) PUSCH transmissions, it is the subsequent PUSCH transmissions that are different from the first PUSCH transmission.

[0161] In summary, this second example of an alternative implementation can avoid RRC signaling overhead and can also avoid additional MAC signaling overhead when transmitting DCI. Furthermore, this second example facilitates providing a mechanism that does not affect the RRC configuration for time domain resource allocation, since the second parameter is implicitly provided in the DCI.

[0162] A further alternative implementation of the present disclosure focuses on the physical layer configuration of the user equipment 410 received from the base station 460, for example, when first accessing a cell broadcasting a particular bandwidth portion for which the PUSCH config IE is applicable. This physical layer configuration can also be referred to as a "physical layer identification of the transmission / reception scenario or service type."

[0163] More specifically, the physical layer configuration signaled between the base station 460 and the user equipment 410 conveys the second parameter. Thus, the processor 430 of these alternative implementations returns to the received physical layer configuration for the purpose of determining, for subsequent PUSCH transmissions, from the second parameter conveyed via the physical layer configuration, whether these transmissions are different (or separate) PUSCH transmissions or repeated PUSCH transmissions.

[0164] [Third example of alternative implementation] In a third example of an alternative implementation, the second parameter may be conveyed via the physical layer configuration in the form of a separate (eg, new) parameter included in the Physical (Phy-) Parameters IE.

[0165] This Phy-parameters IE is received by the receiver 420 of the user equipment 410 in the form of RRC signaling. After receiving the Phy-parameters IE, the processor 430 infers from the same received second parameter whether this parameter indicates a different or repeated PUSCH transmission across the multiple PUSCH transmissions. Thus, this individual (e.g., new) parameter included in the Phy-parameters IE allows explicit signaling of the second parameter between the user equipment 410 and the base station 460.

[0166] For example, a separate (e.g., new) parameter included in the Phy-Parameters IE may be called "pusch-MultipleTransmissions" and may be of the format "ENUMERATED{repeatTB, differentTB]". This parameter may only be taken into account when one DCI is configured to schedule multiple PUSCH transmissions, as is the case in the central aspect of the present disclosure. If one DCI is not configured to schedule multiple PUSCH transmissions, this parameter is not taken into account by the user equipment 410. Such a distinction may apply to all DCIs or may be limited to a specific DCI.

[0167] [Fourth example of alternative implementation] In a fourth example of an alternative implementation, the second parameter may be conveyed via a physical layer configuration in the form of a specific radio frequency band configuration covering a specific bandwidth portion.

[0168] The radio frequency band configuration is received by the receiver 420 of the user equipment 410 in the form of RRC signaling. After receiving the radio frequency band configuration for the particular bandwidth portion for which the PUSCH config IE is applicable, the processor 430 infers the second parameter by checking whether the radio frequency band configuration indicates a particular radio band that can only be used in an unlicensed mode of operation.

[0169] For example, the Industrial, Scientific, and Medical (ISM) radio bands are radio bands (portions of the radio frequency spectrum) that are internationally reserved for the use of radio frequency (RF) energy for industrial, scientific, and medical purposes other than telecommunications. Because of this dedicated purpose, these radio bands can only be used in unlicensed modes of operation.

[0170] If the check for the particular radio band results in "yes", the processor 430 deduces a second parameter indicating that all of the multiple PUSCH transmissions are performed in the form of repeated PUSCH transmissions. If the check for the particular radio band results in "no", the processor 430 deduces a second parameter indicating that all of the multiple PUSCH transmissions are performed in the form of different (or separate) PUSCH transmissions.

[0171] The radio frequency band configuration thus enables implicit signaling of a second parameter between the user equipment 410 and the base station 460. More particularly, by relating the radio frequency band configuration to the same particular bandwidth portion to which the PUSCH config IE is also applicable, the user equipment 410 can implicitly establish a relationship between the unlicensed mode of operation and the need (or requirement) for improved reliability of PUSCH transmissions in that particular bandwidth portion.

[0172] In summary, this fourth example of an alternative implementation can avoid RRC signaling overhead when transmitting DCI and can also avoid additional MAC signaling overhead, and further facilitates providing a mechanism that can consistently guarantee repeated PUSCH transmissions in unlicensed spectrum.

[0173] [Fifth example of alternative implementation] In a fifth example of an alternative implementation, the second parameter may be conveyed via a physical layer configuration in the form of a type of service configuration having specific reliability and / or latency requirements.

[0174] The service type configuration is received by the receiver 420 of the user equipment 410 in the form of RRC signaling. After receiving the service configuration, the processor 430 infers the second parameter by determining whether certain reliability and / or latency requirements of the service type configuration exceed certain target values.

[0175] For example, if processor 430 determines that a particular reliability and / or latency requirement of the service type setting is lower (looser) than a respective target value, processor 430 infers the second value indicating that the multiple PUSCH transmissions are to be performed in the form of different (or separate) PUSCH transmissions. If processor 430 determines that a particular reliability and / or latency requirement is higher (stricter) than a respective target value, processor 430 infers the second value indicating that the multiple PUSCH transmissions are to be performed in the form of repeated PUSCH transmissions.

[0176] Thus, a service type configuration having specific reliability and / or latency requirements allows for implicit signaling of a second parameter between the user equipment 410 and the base station 460.

[0177] [Typical Downlink Scenarios] As already mentioned above, the present disclosure is not limited to transport block (TB) transmission in the uplink, but can equally be applied to downlink transmission, i.e., to achieve flexible support of transport block transmission in the downlink, where again the transport block (TB) transmission is supported with flexible timing without incurring additional signaling overhead.

[0178] In other words, the benefit of improved flexibility when scheduling transport block transmissions is not only achievable for Physical Uplink Shared Channel (PUSCH) transmissions, but equally achievable for Physical Downlink Shared Channel (PDSCH) transmissions, as can be easily derived from the close similarity between the PUSCH-Time Domain Resource Allocation List information element (IE) and the PDSCH-Time Domain Resource Allocation List IE.

[0179] Furthermore, the scheduling described below relies on the PDSCH time domain resource allocation field in DCI format 1-0 or 1-1, which is very similar to the PUSCH time domain resource allocation field in DCI format 0-0 or 0-1 described above, so no additional signaling overhead is incurred.

[0180] Typically, the receiver 420 of the user equipment 410 receives a Physical Downlink Shared Channel (PDSCH) config information element (IE) in the form of radio resource control (RRC) signaling. The PDSCH config IE is applicable to a particular bandwidth portion served by the base station 460.

[0181] The processor 430 of the user equipment 410 then configures a table defined by the PDSCH Time Domain Resource Allocation List IE conveyed in the received PDSCH config IE, where the table configured by the RRC comprises rows, each row having a first set of values associated with time domain resources allocated for multiple PDSCH transmissions.

[0182] The receiver 420 of the user equipment 410 then receives downlink control information (DCI) signaling conveying a time domain resource allocation field with value m, which provides row index m+1 in a table configured by the RRC.

[0183] The processor 430 of the user equipment 410 determines the resources to be allocated for the multiple PDSCH transmissions based on (i) the index of the slot carrying the received DCI and (ii) a first set of values included in an indexed row of a table configured by the RRC that is associated with the time domain resources to be allocated.

[0184] The receiver 420 of the user equipment 410 then receives the multiple PDSCH transmissions, each using the determined allocated time domain resources, and processes the transport blocks of data carried in the multiple received PDSCH transmissions.

[0185] In particular, the transport block of data is processed based on at least one second parameter included in an indexed row of a table configured by the RRC, the second parameter indicating whether the multiple PDSCH transmissions are different PDSCH transmissions or repeated PDSCH transmissions.

[0186] [First exemplary implementation] The following first exemplary implementation is conceived based on the understanding that an indexed row of a table configured by the RRC contains (only) one second parameter, which has either the value "Different" indicating that the subsequent PUSCH transmission is a different (or individual) PUSCH transmission, or the value "Repeat" indicating that the subsequent PUSCH transmission is a repeated PUSCH transmission.

[0187] Since the first PUSCH transmission of multiple PUSCH transmissions is always a different PUSCH transmission, it may seem unnatural to distinguish this first PUSCH transmission from subsequent PUSCH transmissions in the case of (only) one second parameter. In this regard, it is assumed that (only) one second parameter is relevant for all PUSCH transmissions.

[0188] In other words, the indexed row of the table configured by the RRC includes the same one of the at least one second parameter indicating different or repeated PUSCH transmissions for all the multiple PUSCH transmissions.

[0189] The processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH time domain resource allocation list IE.

[0190] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 1. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000001.jpg68170

[0191] [Second exemplary implementation] The following second example implementation is conceived based on the understanding that the indexed rows of the table configured by the RRC include individual second parameters for subsequent PUSCH transmissions, each of which has either the value "Different" to indicate that the respective subsequent PUSCH transmission is a different (e.g., individual) PUSCH transmission compared to the preceding PUSCH transmission, or the value "Repeat" to indicate that the respective subsequent PUSCH transmission is a repeated PUSCH transmission compared to the preceding PUSCH transmission.

[0192] In other words, the indexed row of the table configured by the RRC includes, for each of the multiple PUSCH transmissions except for the first PUSCH transmission of the multiple PUSCH transmissions, a different parameter of the at least one second parameter indicating a different PUSCH transmission or a repeated PUSCH transmission.

[0193] The processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH time domain resource allocation list IE.

[0194] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 2. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000002.jpg67170

[0195] [Third Exemplary Implementation] The following third exemplary implementation is conceived based on the understanding that at least one of the third set of values included in the indexed row of the table configured by the RRC is at least one of a value K2′ indicating another slot offset for the at least one subsequent PUSCH transmission, a value SLIV′ indicating another start-length indicator value for the at least one subsequent PUSCH transmission, and / or a value indicating the number of the at least one subsequent PUSCH transmission.

[0196] In particular, the further start-length indicator value SLIV' comprises a value S' indicating a symbol number specifying the start of the time domain resources allocated for at least one subsequent PUSCH transmission and a value L' indicating a number of symbols specifying the length of the time domain resources allocated for at least one subsequent PUSCH transmission.

[0197] According to the above understanding, the table configured by the RRC not only includes values from the first value set that specify the time domain resources allocated for the first PUSCH transmission. In addition, the table configured by the RRC includes a third value set that includes values K2′ and / or SLIV′ that specify the time domain resources allocated for at least one subsequent PUSCH transmission. Furthermore, the third value set includes a value that indicates the number of at least one subsequent PUSCH transmission, further complementing the table configured by the RRC in enabling more flexibility in determining which of the specified allocated time domain resources to use for the subsequent PUSCH transmission.

[0198] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH time domain resource allocation list IE.

[0199] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 3. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000003.jpg73170

[0200] [Fourth Exemplary Implementation] The following fourth example implementation is conceived based on the understanding that an indexed row of the table configured by the RRC includes at least one fourth value associated with generating multiple PUSCH transmissions, the at least one fourth value assisting the user equipment in generating multiple PUSCH transmissions carrying selected transport blocks of data.

[0201] In other words, the transmitter 420 of the user equipment 410 generates multiple PUSCH transmissions carrying selected transport blocks of data based on at least one fourth value associated with generating the multiple PUSCH transmissions, the at least one fourth value also being included in an indexed row of a table configured by the RRC.

[0202] An example of the fourth value is a different modulation and coding scheme (MCS) index value for each of the multiple PUSCH transmissions, except for the first PUSCH transmission of the multiple PUSCH transmissions. In other words, the indexed row of the RRC-configured table includes a different modulation and coding scheme (MCS) index value for each of the subsequent PUSCH transmissions.

[0203] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH time domain resource allocation list IE.

[0204] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 4-1. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000004.jpg68170

[0205] By using such different MCS index values for each subsequent PUSCH transmission, the present disclosure is able to more accurately match the MCS index to the channel conditions for each transmission.

[0206] Another example of the fourth value is the same modulation and coding scheme (MCS) index value (e.g., maximum robustness index value) for all multiple PUSCH transmissions. In other words, an indexed row of the table configured by the RRC contains the same modulation and coding scheme (MCS) index value for all multiple PUSCH transmissions.

[0207] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH time domain resource allocation list IE.

[0208] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 4-2. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000005.jpg66170

[0209] A further example of the fourth value is a different redundancy version (RV) offset value for each of the multiple PUSCH transmissions, except for the first PUSCH transmission of the multiple PUSCH transmissions. In other words, an indexed row of the table configured by the RRC includes a different redundancy version (RV) offset value for each of the subsequent PUSCH transmissions.

[0210] For example, assume now that a DCI having an RV field containing a value of "1" is received by the receiver 420 of the user equipment 410, the transmitter 420 generates the first PUSCH transmission of the multiple PUSCH transmissions using an RV of "1" as determined by the RV field of the DCI with a value of "1". Further, the transmitter generates subsequent PUSCH transmissions of the multiple PUSCH transmissions using an RV of "1" plus a respective RV offset value for each subsequent PUSCH transmission from the indexed row of the table configured by the RRC.

[0211] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH time domain resource allocation list IE.

[0212] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 4-3. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000006.jpg68170

[0213] By using such different RV offset values for each subsequent PUSCH transmission, the present disclosure allows for greater flexibility when scheduling different PUSCH transmissions, in other words, an independent RV offset can be used for each PUSCH transmission.

[0214] A further example of the fourth value is the same redundancy version (RV) offset value for each of the multiple PUSCH transmissions except for the first PUSCH transmission of the multiple PUSCH transmissions. In other words, an indexed row of the table configured by the RRC includes the same redundancy version (RV) offset value for each of the subsequent PUSCH transmissions.

[0215] For example, assume now that a DCI having an RV field containing a value of "1" is received by the receiver 420 of the user equipment 410, the transmitter 420 will generate the first PUSCH transmission as well as subsequent PUSCH transmissions of the plurality using an RV of "1" plus the same RV offset value for all the plurality of PUSCH transmissions from the indexed row of the table configured by the RRC.

[0216] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH time domain resource allocation list IE.

[0217] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 4-4. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000007.jpg66170

[0218] [Fifth Exemplary Implementation] The following fifth example implementation is conceived based on the understanding that an indexed row of the table configured by the RRC includes at least one fifth parameter related to generating multiple PUSCH transmissions, the at least one fifth parameter assisting the user equipment in generating multiple PUSCHs carrying selected transport blocks of data.

[0219] At least one fifth parameter related to the generation of the multiple PUSCH transmissions is further included in a PUSCH time domain resource allocation list IE defining a table created by the processor 430 of the user equipment 410 or the processor 480 of the base station 460.

[0220] In other words, the transmitter 420 of the user equipment 410 generates multiple PUSCHs carrying selected transport blocks of data according to principles defined by at least one fifth parameter related to the generation of the multiple PUSCH transmissions, which is also included in an indexed row of a table configured by the RRC.

[0221] An example of a fifth parameter that specifies principles related to the generation of the multiple PUSCH transmissions is a parameter that indicates whether a transport block size (TBS) is calculated for each of the multiple PUSCH transmissions individually or whether a combined transport block size of all PUSCH transmissions is calculated.

[0222] For example, assume that DCI containing transport block sizes (TBS) for multiple PUSCH transmissions is received by a receiver 420 of a user equipment 410. In this case, the transmitter 420 needs to know whether the TBS is calculated for each PUSCH transmission individually or as the combined TBS of all PUSCH transmissions.

[0223] In the first case, the transmitter 420 generates PUSCH transmissions that each have the same TBS from the DCI. In the second case, the transmitter generates PUSCH transmissions that each have TBS that correspond to the combined TBS from the DCI divided by the total number of PUSCH transmissions. In either case, the transmitter 420 can generate multiple PUSCH transmissions by following the principles defined by at least one fifth parameter.

[0224] Another example of a fifth parameter that specifies principles related to the generation of multiple PUSCH transmissions is a parameter that indicates whether a modulation and coding scheme (MCS) index is determined individually for each of the multiple PUSCH transmissions or whether the same MCS index is determined for all PUSCH transmissions.

[0225] In other words, the transmitter 420 uses this parameter, which indicates the determination principle of the modulation and coding scheme (MCS) index, to generate subsequent PUSCH transmissions according to the same MCS as the first transmission, or by calculating the MCS for each subsequent transmission based on the transport block size and available resources for each subsequent transmission.

[0226] While each transmission is indicated to use the same MCS, if the transport block sizes are different, each transmission may be of different length, in which case the transmitter determines the MCS according to the same principles as for the first PUSCH transmission.

[0227] When the MCS needs to be determined for each subsequent PUSCH transmission after the first PUSCH transmission, the closest MCS value is calculated compared to the MCS value of the first transmission depending on the transport block size and resources.

[0228] An example of a PUSCH time-domain resource allocation list IE containing parameters indicating the determination principle of the modulation and coding scheme (MCS) index is reproduced below, namely as Example 5. As the terminology may change in the future, this example shall be understood more broadly in terms of the functionality and concepts conveying additional parameters included in the PUSCH time-domain resource allocation list IE. JPEG0007720954000008.jpg68170

[0229] A further example of a fifth parameter that specifies the principles related to the generation of multiple PUSCH transmissions is a parameter that indicates whether to determine the same redundancy version (RV) for all multiple PUSCH transmissions based on the RV field in the received DCI.

[0230] Alternatively, no additional parameter may be introduced to indicate the RV of a subsequent PUSCH transmission of multiple PUSCH transmissions, in which case the transmitter 420 of the user equipment 410 reuses the same RV as the RV of the first PUSCH transmission, which is explicitly determined by the RV field of the DCI received by the receiver 420.

[0231] A further example of a fifth parameter that defines principles related to the generation of multiple PUSCH transmissions is a parameter that indicates whether demodulation reference symbols (DMRS) are present in at least the first PUSCH transmission or in all of the multiple PUSCH transmissions.

[0232] [Comprehensive example of the first common uplink scenario] 8 and 9, a comprehensive example is presented that combines the effects described in the first general scenario with the effects of a number of exemplary implementations, although this example should not be understood as a limitation on the present disclosure as alternative combinations are also possible.

[0233] In particular, the example is presented in the form of an RRC configured table for multiple PUSCH transmissions and the corresponding time domain resource allocation for multiple PUSCH transmissions.

[0234] The RRC configured table is again configured by the processor 430 of the user equipment 410, i.e., according to the parameters contained in the PUSCH time domain resource allocation list IE, as explained above. What is important below is to explain how the processor 430 and the transmitter 420 cooperate to perform multiple PUSCH transmissions utilizing the RRC configured table.

[0235] In this table, shown in Figure 8, multiple values / parameters are combined and are referred to as a first set of values, a second parameter, a third set of values, a fourth value, and a fifth parameter. The numbers are not given for any particular reason, such as to distinguish between different levels of importance or to indicate an order of use. Instead, the numbers are given as unique reference numbers to clearly distinguish between them.

[0236] For example, the value K2 and the value K2' cannot be confused because the value K2 is included in (and belongs to) a first set of values, while the value K2' is included in (and belongs to) a third set of values. However, these multiple values / parameters are grouped based on their functionality to associate similar operations performed by the processor 430 and the transmitter 420 before multiple PUSCH transmissions are made.

[0237] In this example, assume that the processor 430 configures the table shown in FIG. 8 defined by the PUSCH Time Domain Resource Allocation List IE, and that the receiver receives a DCI scheduling a total of three PUSCH transmissions, where the DCI conveys a time domain resource allocation field with m equal to the value 2 (thus providing 3 as the row index m+1 in the table).

[0238] The three scheduled PUSCH transmissions can be individually referred to as PUSCH transmissions #1, #2, and #3, or can be understood as the first PUSCH transmission (#1) and subsequent PUSCH transmissions (#2 and #3).

[0239] The processor 430 returns to the first parameter set in the indexed row with row index 3 of the RRC configured table to determine the time domain resources allocated for the first PUSCH transmission (#1).

[0240] From the value indicating the PUSCH mapping type, the processor 430 infers that the PUSCH mapping type is Type b, which means that the resource allocation can start within a slot and does not necessarily have to start at the beginning of the slot, and this Type b is not only applicable to the first PUSCH transmission but also to subsequent PUSCH transmissions.

[0241] Processor 430 further infers from value K2 that the time domain resources allocated for the first PUSCH transmission are contained in the slot with slot number k + 2. Processor 430 also infers from values S and L that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot with slot number k + 2 and have a length of 4 symbols.

[0242] The processor 430 returns to the third parameter set in the indexed row having row index 3 to determine the time domain resources allocated for subsequent PUSCH transmissions (#2 and #3).

[0243] The processor 430 infers from the value K2′ that the time domain resources allocated for the subsequent PUSCH transmissions #2 and #3 are included in a slot determined by the value k corresponding to the slot index carrying the received DCI.

[0244] Thus, the time domain resources allocated for subsequent PUSCH transmissions #2 and #3 are contained in slots k+2 and k+3, respectively. Additionally, two values S' and two values L' are included, indicating that the resources allocated for subsequent PUSCH transmissions #2 and #3 start at symbol number 6 and symbol number 1 in slots k+2 and k+3, respectively. The respective resource allocations in the time domain are also shown.

[0245] The processor 430 returns to the second parameter in the indexed row with row index 3 of the RRC configured table to select a transport block of data to send in the scheduled PUSCH transmission.

[0246] The processor 430 infers from the values {R, D} included as the second parameter whether the subsequent PUSCH transmissions #2, #3 are different PUSCH transmissions or repeated PUSCH transmissions.

[0247] For the subsequent PUSCH transmission #2, the second parameter with value R, meaning repeat of the previous PUSCH transmission, indicates that the same transport block of data should be selected, repeating the transport block of the previous PUSCH transmission #1. For the subsequent PUSCH transmission #3, the second parameter with value D, meaning different from the previous PUSCH transmission, indicates that a new transport block of data should be selected, different from the transport block of the previous PUSCH transmission #2.

[0248] In other words, the second parameter defines whether the subsequent PUSCH transmission is a repetition of or different from the preceding PUSCH transmission.

[0249] The processor 430 returns to the TBS determination parameter of the fifth parameter in the indexed row with row index 3 of the table configured by the RRC to more efficiently select a transport block of data.

[0250] The processor 430 infers from the TBS determination parameter, which has a value C that indicates TBS individual calculation, that the transport block size should be calculated for each PUSCH transmission individually. This calculation requires further information obtained by the processor 430.

[0251] In particular, the processor 430 further returns to the MCS decision parameter of the same fifth parameter in the indexed row with row index 3 of the table configured by the RRC.

[0252] The processor 430 infers that the same modulation and coding scheme (MCS) index is determined for all PUSCH transmissions from the MCS determination parameter having a value S indicating the determination of the same MCS. In this regard, the processor 430 determines that the transmitter 420 can generate the first PUSCH transmission #1 and subsequent PUSCH transmissions #2 and #3 using the same MCS corresponding to the MCS field in the scheduling DCI.

[0253] The transmitter 420 reverts to the MCS field in the scheduling DCI for the MCS index that should actually be used, and also to the fourth value MCS index value contained in the indexed row of the table configured by the RRC.

[0254] More specifically, the transmitter 420 returns to the indexed row of the table configured by the RRC and checks whether the MCS index value is among the fourth values contained in the same table. In this case, the transmitter 420 finds an MCS index value of 4. Knowing that an MCS index value has been found and that the same MCS value should be used for all PUSCH transmissions #1, #2, and #3, the transmitter uses this MCS index value of 4 instead of referencing the MCS field in the scheduling DCI when generating the PUSCH transmissions.

[0255] Thus, at this point, processor 430 may also calculate a TBS for each of the multiple PUSCH transmissions individually.

[0256] In particular, processor 430 determines that because all PUSCH transmissions have the same symbol length (L=4) and should be generated using the same MCS, the transport block size (TBS) of each of the PUSCH transmissions should also be calculated identically. In other words, processor 430 infers that the same amount of time-domain resources (all PUSCHs have the same length L=4) and the same MCS will result in the same TBS for all PUSCH transmissions #1, #2, and #3, even if calculated individually, even if the MCS determination parameter indicates that the MCS should be calculated individually.

[0257] For the TBS values to actually be used, the transmitter 420 goes back to the TBS values included in the DCI scheduling multiple PUSCH transmissions and calculates each TBS value by dividing the TBS value from the DCI by the total number of PUSCHs.

[0258] Further, the processor 430 infers from the fifth parameter, the RV parameter N, that the redundancy version (RV) indexes used in generating all of the PUSCH transmissions are not the same for all PUSCH transmissions. Because the RV indexes are not the same, the transmitter 420 returns to the fourth parameter, the RV offset value, and uses this RV offset value to determine the RV indexes for subsequent PUSCH transmissions.

[0259] For the RV to actually be used, the transmitter 420 reverts to the RV field included in the DCI scheduling multiple PUSCH transmissions and to the fourth value RV offset value included in the indexed row of the table configured by the RRC.

[0260] More specifically, when generating a PUSCH transmission, the transmitter 420 determines RV0 for the first PUSCH transmission #1 based on the RV field of the DCI, and determines RV1 for subsequent PUSCH transmissions #2 and #3 based on adding an RV offset 1 corresponding to the fourth parameter in the indexed row with row index 3 of the table configured by the RRC to the RV field of the DCI.

[0261] Finally, the processor 430 returns to the DMRS parameter of the fifth parameter in the indexed row of the table and infers from the DMRS parameter F, which means DMRS only at the beginning, that the demodulation reference symbol (DMRS) is present only in the first PUSCH transmission among the multiple PUSCH transmissions.

[0262] Finally, PUSCH transmissions #1, #2, and #3 are generated and transmitted by the PUSCH transmitter using the allocated time domain resources, as shown in FIG.

[0263] [Second common uplink scenario] 10 and 11 respectively depict another exemplary implementation according to a second general scenario of the configuration blocks of the user equipment 410 and the base station 460. The user equipment 410 of this exemplary implementation includes a PUSCH config IE receiver 1020-a, a table configuration processing circuit 1030-a, a DCI receiver 1020-b, a configured grant config IE receiver 1020-c, an assigned resource determination processing circuit 1030-b, and a PUSCH transmitter 1020-d.

[0264] Similarly, the base station 460 of this exemplary implementation includes a PUSCH config IE transmitter 1170-a, a table configuration processing circuit 1180-a, a DCI transmitter 1170-b, a configured grant config IE transmitter 1170-c, a resource allocation processing circuit 1180-b, and a PUSCH receiver 1170-d.

[0265] In general, this disclosure assumes that user equipment 410 is within communication range of base station 460 and is configured to use at least one bandwidth portion on the downlink and at least one bandwidth portion on the uplink, which are located within the carrier bandwidth served by base station 460.

[0266] Furthermore, this disclosure assumes that the user equipment 410 is operating in a radio resource control (RRC) connected state (referred to as RRC_CONNECTED) and is therefore capable of receiving data and / or control signals from the base station 460 on the downlink and transmitting data and / or control signals to the base station 460 on the uplink.

[0267] Before performing PUSCH repetition as proposed in the present disclosure, the user equipment 410 receives control messages defined in the radio resource control (RRC) protocol layer and the medium access control (MAC) protocol layer, i.e., employs signaling mechanisms that are readily available in different protocol layers of various communication technologies.

[0268] In general, there is a substantial difference between the control messages defined in RRC and those defined in MAC. This difference is already apparent since RRC control messages are typically used to semi-statically configure radio resources (e.g., radio links), while MAC control messages are used to dynamically define each medium access (e.g., transmission) individually. From this point of view, it can be immediately seen that RRC control occurs less frequently than MAC control.

[0269] Therefore, RRC control messages have been tolerated in standardization, whereas excessive MAC control signaling overhead can substantially degrade the performance of a communication system, or in other words, MAC control signaling overhead is generally recognized as a constraint on system performance.

[0270] For this reason, conventional mechanisms for PUSCH repetition rely on a pre-specified (e.g., fixedly defined in the relevant standard) timing relationship between the initial PUSCH transmission and its repetitions. In other words, the risk of degrading system performance has been found to outweigh the benefits of using PUSCH repetition more flexibly.

[0271] In view of the above, the authors of the present disclosure propose a mechanism that overcomes the drawbacks of conventional mechanisms and allows flexible repetition of transport blocks (TBs) while avoiding signaling overhead.

[0272] In the context of the present invention, the term "transport block" should be understood as a data unit for uplink and / or downlink transmission. For example, the term "transport block" is widely understood to be equivalent to a packet data unit (PDU) at the MAC layer. Therefore, a transmission of a transport block is equally understood as a physical uplink shared channel (PUSCH) transmission and / or a physical downlink shared channel (PDSCH) transmission.

[0273] In particular, because PUSCH and / or PDSCH transmissions typically carry a payload, this disclosure refers to PUSCH and / or PDSCH transmissions carrying a MAC PDU. In other words, the term "PUSCH and / or PDSCH transmission" should be understood to describe transmitting a MAC PDU on a PUSCH and / or PDSCH.

[0274] With reference to FIG. 12, a general scenario relating to performing PUSCH repetition based on a dynamic grant, i.e., a DCI conveying a time domain resource allocation field (e.g., a DCI of DCI format 0-0 or a DCI of DCI format 0-1, etc.) will be described.

[0275] However, this description should not be construed as limiting the present disclosure solely to extensions of PUSCH transmissions (and more specifically, repetitions of PUSCH transmissions).It will become apparent that the concepts disclosed herein are equally applicable to downlink transmissions.

[0276] The receiver 420 of the user equipment 410 receives a physical uplink shared channel (PUSCH) config information element (IE) (see, e.g., step 1210 of FIG. 12). This PUSCH config IE is received in the form of radio resource control (RRC) signaling and is applicable to a particular bandwidth portion. This PUSCH config IE is received from the base station 460 serving that particular bandwidth portion. This receiving operation can be performed, for example, by the PUSCH config IE receiver 1020-a of FIG. 10.

[0277] The PUSCH config IE conveys a list of parameters in the form of an information element (IE) called "PUSCH-TimeDomainResourceAllocationList," in particular, and each parameter in this parameter list is called a "PUSCH-TimeDomainResourceAllocation."

[0278] The processor 430 of the user equipment 410 then configures a table defined by the PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE (see, for example, step 1220 of FIG. 12). The table comprises rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator. This configuration operation can be performed, for example, by the table configuration processing circuit 1030-a of FIG. 10.

[0279] In one example implementation, each row of the table configured by the RRC corresponds to one of a number of parameters called "PUSCH-TimeDomainResourceAllocation" in a parameter list called "PUSCH-TimeDomainResourceAllocationList", however, this should not be understood as a limitation to the present disclosure, as will be evident from the following alternative scenario.

[0280] Scenarios that differ from this exemplary implementation are also possible, in which some rows of the configured table correspond to the respective parameters contained in the IE with the parameter list, and other rows are configured according to a pre-specified set of rules that directly apply the principles laid out in the PUSCH Time Domain Resource Allocation List IE.

[0281] However, even in these scenarios, the entire table configured by the RRC is still defined by the PUSCH Time Domain Resource Allocation List IE.

[0282] The receiver 420 of the user equipment 410 then receives downlink control information (DCI) signaling (see, e.g., step 1230 of FIG. 12). This DCI conveys a time-domain resource allocation field with value m, which provides row index m+1 in the configured table. This receiving operation can be performed, for example, by the DCI receiver 1020-b of FIG. 10.

[0283] In the context of the present disclosure, this DCI conveys an uplink grant because it serves the purpose of triggering PUSCH repetitions. In this respect, the received DCI is DCI format 0-0 or DCI format 0-1. In this respect, the described scenario refers to a situation in which PUSCH repetitions are scheduled by a dynamic grant.

[0284] However, this should not be understood as a limitation on the present disclosure, as the concepts disclosed herein are equally applicable to configured grant or grant-free scheduling techniques, a detailed description of which is provided as an alternative to the mechanism depicted in FIG.

[0285] The processor 430 of the user equipment 410 then determines the resources allocated for the initial PUSCH transmission and the resources allocated for at least one repetition of the initial PUSCH transmission. For clarity and brevity, the following description focuses on the allocation of time-domain resources. This determination operation can be performed, for example, by the allocated resource determination processing circuit 1030-b of FIG. 10.

[0286] The resources used by the user equipment 410 for the initial PUSCH transmission and its repetition(s) have been previously allocated by the base station 460. Thus, in this context, the processor 430 determines which of the previously allocated resources to use for the PUSCH transmission and its repetition(s).

[0287] As part of this determination operation, processor 430 first determines the resources to be allocated for the first PUSCH transmission based on (i) the index of the slot carrying the received DCI, (ii) a slot offset value K2 contained in the indexed row of the table configured by the RRC, and (iii) a start-length indicator value SLIV (see, e.g., step 1240 of FIG. 12 ), which means that processor 430 previously determined that the value indicating the PUSCH mapping type indicates a Type B mapping.

[0288] For example, assume that the received DCI is carried in slot number k and has a time-domain resource allocation field with value m. In this case, for the first PUSCH transmission, the processor returns to row index m+1 of the table configured by the RRC and uses value K2 indicating the slot offset and value SLIV indicating the start-length indicator. Using these values, the processor determines that the resources allocated for the first PUSCH transmission are contained in slot number k+K2 and have a starting position and length in this slot, in symbols, that correspond to value SLIV.

[0289] When determining the allocated resources, the processor 430 also uses a value indicating a PUSCH mapping type further contained in the row with row index m+1 of the table configured by the RRC. In particular, if this value indicates a PUSCH mapping of type A, the processor 430 uses only the length of the value SLIV indicating the start and length indicator. If this value indicates a PUSCH mapping of type B, the processor 430 uses both the start and length of the value SLIV indicating the start and length indicator.

[0290] As part of this determining operation, processor 430 then determines the resources allocated for at least one repetition of the initial PUSCH transmission. To this end, processor 430 checks whether there are (explicit) parameters (e.g., timing) related to the time domain resource allocation for the repetition (see, e.g., step 1250 of FIG. 12). To this end, processor 430 returns to the row with row index m+1 and checks whether this row contains additional values (e.g., at least one value) specifying the time domain resources allocated for at least one repetition of the initial PUSCH transmission.

[0291] If the check results in "no," the processor 430 uses a conventional slot-based repetition mechanism for the repetition of the initial PUSCH transmission (see, e.g., step 1260 of FIG. 12). In other words, the processor 430 relies on a pre-specified (e.g., fixedly defined in the relevant standard) timing relationship between the initial PUSCH transmission and its repetition. For example, this can result in the initial PUSCH transmission and each repetition starting from the same symbol of multiple consecutive slots and having the same symbol length.

[0292] Referring to this example, the processor 430 returns, for at least one repetition, to the row with row index m+1 of the table configured by the RRC and determines that the resource to be allocated for the first repetition of the first PUSCH transmission is contained in slot number k+K2+1 (1 is a predefined constant fixed by standardization) and has a starting position and length in that slot, expressed in symbols, corresponding to the same value SLIV.

[0293] If there is a second repetition, processor 430 determines that the resources allocated for the second repetition of the initial PUSCH transmission are contained in slot number k+K2+2 (where 2 is again a predefined constant fixed by standardization) and have a starting position and length in that slot, in symbols, corresponding to the same value SLIV as for the initial PUSCH transmission and its first repetition. Further repetitions follow in successive slots.

[0294] Further assuming in this example that the PUSCH mapping type indicated in the row with row index m+1 is Type B, and that the value SLIV indicates a start at symbol 4 and a length of 4 symbols, processor 430 determines that the initial PUSCH transmission, the first repetition, and the second repetition of that PUSCH transmission each have resources corresponding to symbol 4, symbol 5, symbol 6, and symbol 7 in slots numbered k+K2, k+K2+1, and k+K2+2, respectively.

[0295] Obviously, these allocated resources determined by the processor 430 cannot be flexibly configured. This is overcome by the following alternative determination method by the processor 430.

[0296] If the check results in "yes", the processor 430 uses the additional value (e.g., at least one value) contained in the indexed row of the table configured by the RRC (see, for example, step 1270 of FIG. 12) for the purpose of determining the resources allocated for the repetition of the first PUSCH transmission. In other words, the at least one additional value contained specifies the resources allocated for the repetition of the first PUSCH transmission.

[0297] It should be emphasized here that the at least one additional value is included in a row of the RRC configured table that is defined by the PUSCH Time Domain Resource Allocation List IE, in other words, since the RRC configured table (as a whole) is defined by the PUSCH Time Domain Resource Allocation List IE, the at least one additional value included in this table is also defined by the PUSCH Time Domain Resource Allocation List IE.

[0298] To meet this constraint, the at least one additional value may be (directly) specified by a parameter contained in the PUSCH Time Domain Resource Allocation List IE, or alternatively, the at least one additional value may be (indirectly) inferred from a related parameter contained in the PUSCH Time Domain Resource Allocation List IE. In either case, the at least one additional value specifies a repetition of the initial PUSCH transmission in the time domain.

[0299] It is important to note that the processor 430 of the user equipment 410 uses additional values from an indexed row of a table configured by the RRC to determine the resources allocated for repetition. This method differs substantially from the conventional slot-based repetition mechanism for the following reasons:

[0300] First, the at least one additional value is obtained from a row of a table configured by the RRC that is (actively) indexed by a row index m+1, which is derived from the value m in the time domain resource allocation field of the received DCI. In this respect, by varying the index value m in the time domain resource allocation field of the received DCI, it is possible to vary the at least one additional value that is used to determine the resources allocated for at least one repetition of the first PUSCH transmission, thus increasing the flexibility of the resources allocated in this way.

[0301] Second, the at least one additional value is taken from the (same) row of the table configured by the RRC that is (already) indexed by row index m+1, which is derived from value m in the time domain resource allocation field of the received DCI. In this respect, no additional index value other than index value m in the time domain resource allocation field of the received DCI is needed when determining the resources to be allocated for at least one repetition of the first PUSCH transmission. Thus, additional signaling overhead is avoided.

[0302] As a result, this allows for increased flexibility while avoiding signaling overhead, i.e. the processor 430 of the user equipment 410 determines the resources allocated for repetition using at least one additional value from an indexed row of a table configured by the RRC.

[0303] Finally, the transmitter 420 of the user equipment 410 transmits the PUSCH transmission using the determined resources allocated for the initial PUSCH transmission and its at least one repetition (not shown in FIG. 12). This transmission operation may be performed, for example, by the PUSCH transmitter 520-f of FIG. 5.

[0304] The above description is made from the perspective of the user equipment 410. However, this should not be understood as a limitation on the present disclosure. The base station 460 equally performs the general scenarios disclosed herein.

[0305] The transmitter 470 of the base station 460 transmits a Physical Uplink Shared Channel (PUSCH) config information element (IE) in the form of radio resource control (RRC) signaling. This PUSCH config IE is applicable to a specific bandwidth portion. This transmission operation can be performed, for example, by the PUSCH config IE transmitter 1170-a of FIG. 11.

[0306] The processor 480 of the base station 460 then configures a table defined by the PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE. This RRC-configured table comprises rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator. This configuration operation can be performed, for example, by the table configuration processing circuit 1180-a of FIG. 11.

[0307] The transmitter 470 of the base station 460 then transmits downlink control information (DCI) signaling conveying a time-domain resource allocation field with value m, which provides row index m+1 in a table configured by the RRC. This transmission operation can be performed, for example, by the DCI transmitter 1170-b of FIG. 11.

[0308] The processor 480 of the base station 460 allocates resources for the initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission based on (i) the index of the slot carrying the DCI to be transmitted, (ii) a value K2 indicating a slot offset contained in the indexed row of the table configured by the RRC, and (iii) a value SLIV indicating a start-length indicator.

[0309] In particular, the determination of the allocated resources is based on at least one additional value included in an indexed row of a table configured by the RRC, which specifies the time-domain resources allocated for at least one repetition of the initial PUSCH transmission. This resource allocation operation can be performed, for example, by the resource allocation processing circuit 1180-b of FIG. 11.

[0310] Finally, receiver 470 of base station 460 receives the PUSCH transmission using the resources allocated for the initial PUSCH transmission and for at least one repetition thereof, which may be performed, for example, by PUSCH receiver 1170-d of FIG.

[0311] In the following, a general scenario is described that relates to performing PUSCH repetition based on configured grant (or grant-free) (i.e., configured grant config IE received in the form of RRC signaling) and further including a PUSCH time domain resource allocation list IE.

[0312] The receiver 420 of the user equipment 410 receives a physical uplink shared channel (PUSCH) config information element (IE) in the form of radio resource control (RRC) signaling. This PUSCH config IE is applicable to a particular bandwidth portion. The PUSCH config IE is received from the base station 460 that serves that particular bandwidth portion. This receiving operation can be performed, for example, by the PUSCH config IE receiver 1020-a of FIG. 10.

[0313] The processor 430 of the user equipment 410 then configures a table defined by the PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE. This RRC-configured table comprises rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator. This configuration operation can be performed, for example, by the table configuration processing circuit 1030-a of FIG. 10.

[0314] The receiver 420 of the user equipment 410 then receives in the form of RRC signaling a configured grant config IE conveying a time domain resource allocation field with value m, which provides row index m+1 in the table to be configured. This receiving operation can be performed, for example, by the configured grant config IE receiver 1020-c of FIG. 10.

[0315] The processor 430 of the user equipment 410 determines the resources allocated for the initial PUSCH transmission and the resources allocated for at least one repetition of the initial PUSCH transmission based on (i) the value of the time domain offset field further conveyed in the received configured grant config IE and associated with the time domain resource allocation field, (ii) a value K2 indicating a slot offset contained in the indexed row of the table configured by the RRC, and (iii) a value SLIV indicating a start-length indicator.

[0316] In particular, the determination of the allocated resources is based on at least one additional value included in an indexed row of a table configured by the RRC, which specifies the time domain resources allocated for at least one repetition of the initial PUSCH transmission. This determination operation can be performed, for example, by the allocated resource determination processing circuit 1030-b of FIG. 10.

[0317] Finally, the transmitter 420 of the user equipment 410 transmits the PUSCH transmission using the determined allocated resources for the initial PUSCH transmission and for at least one repetition thereof, which may be performed by, for example, the PUSCH transmitter 1030-d of FIG.

[0318] The above description is made from the perspective of the user equipment 410. However, this should not be understood as a limitation on the present disclosure. The base station 460 equally performs the general scenarios disclosed herein.

[0319] The transmitter 470 of the base station 460 transmits a physical uplink shared channel (PUSCH) config information element (IE) in the form of radio resource control (RRC) signaling, where the PUSCH config IE is applicable to a particular bandwidth portion. This transmission operation can be performed, for example, by the PUSCH config IE transmitter 1170-a of FIG. 11.

[0320] The processor 480 of the base station 460 then configures a table defined by the PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE. This RRC-configured table comprises rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator. This configuration operation can be performed, for example, by the table configuration processing circuit 1180-a of FIG. 11.

[0321] The transmitter 470 of the base station 460 then transmits, in the form of RRC signaling, a configured grant config IE conveying a time domain resource allocation field with value m, which provides row index m+1 in the table configured by the RRC. This transmission operation can be performed, for example, by the configured grant config IE transmitter 1170-c of FIG. 11.

[0322] The processor 480 of the base station 460 allocates resources for the initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission based on (i) the value of the time domain offset field that is further conveyed in the transmitted configured grant config IE and associated with the time domain resource allocation field, (ii) a value K2 indicating a slot offset contained in the indexed row of the table configured by the RRC, and (iii) a value SLIV indicating a start-length indicator.

[0323] In particular, the determination of the allocated resources is based on at least one additional value included in an indexed row of a table configured by the RRC, which specifies the time-domain resources allocated for at least one repetition of the initial PUSCH transmission. This resource allocation operation can be performed, for example, by the resource allocation processing circuit 1180-b of FIG. 11.

[0324] Finally, receiver 470 of base station 460 receives the PUSCH transmission using the determined allocated resources for the initial PUSCH transmission and for at least one repetition thereof, which may be performed, for example, by PUSCH receiver 1170-d of FIG.

[0325] [Typical Downlink Scenarios] As already mentioned above, the present disclosure is not limited to transport block (TB) repetition in the uplink, but can equally be applied to downlink transmissions, i.e. to achieve flexible support of repetition in the downlink, where again transport block (TB) repetition is supported with flexible timing without incurring additional signaling overhead.

[0326] In other words, the benefit of improved flexibility when scheduling transport block repetitions is not only achievable for Physical Uplink Shared Channel (PUSCH) transmissions, but equally achievable for Physical Downlink Shared Channel (PDSCH) transmissions, which follows easily from the close similarity between the PUSCH time domain resource allocation list information element (IE) and the PDSCH time domain resource allocation list IE.

[0327] Furthermore, the scheduling described below relies on the PDSCH time domain resource allocation field in DCI format 1-0 or 1-1, which is very similar to the PUSCH time domain resource allocation field in DCI format 0-0 or 0-1 described above, so no additional signaling overhead is incurred.

[0328] Typically, the receiver 420 of the user equipment 410 receives a Physical Downlink Shared Channel (PDSCH) config information element (IE) in the form of radio resource control (RRC) signaling. The PDSCH config IE is applicable to a particular bandwidth portion served by the base station 460.

[0329] The processor 430 of the user equipment 410 then configures a table defined by the PDSCH Time Domain Resource Allocation List IE conveyed in the received PDSCH config IE. The table configured by the RRC comprises rows, each row having a value indicating a PDSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator.

[0330] The receiver 420 of the user equipment 410 then receives downlink control information (DCI) signaling conveying a time domain resource allocation field with value m, which provides row index m+1 in a table configured by the RRC.

[0331] The processor 430 of the user equipment 410 determines the resources allocated for the initial PDSCH transmission and the resources allocated for at least one repetition of the initial PDSCH transmission based on (i) the index of the slot carrying the received DCI, (ii) a value K2 indicating a slot offset contained in the indexed row of the table configured by the RRC, and (iii) a value SLIV indicating a start-length indicator.

[0332] In particular, the determination of the allocated resources is based on at least one additional value contained in an indexed row of a table configured by the RRC that specifies the time domain resources to be allocated for at least one repetition of the initial PDSCH transmission.

[0333] Finally, the receiver 420 of the user equipment 410 receives the PDSCH transmission using the allocated resources determined for the initial PDSCH transmission and for its at least one repetition, respectively.

[0334] [Sixth Exemplary Implementation] The following sixth exemplary implementation is conceived based on the understanding that the at least one additional value included in the indexed row of the table configured by the RRC is at least one of a value K2' indicating a second slot offset for at least one repetition, a value SLIV' indicating a second start-length indicator value for at least one repetition, and optionally a value indicating the number of at least one repetition.

[0335] In particular, the second start-length indicator value SLIV' comprises a value S' indicating a symbol number specifying the start of the resources allocated for at least one repetition, and a value L' indicating a number of symbols specifying the length of the resources allocated for at least one repetition.

[0336] According to the above understanding, the RRC-configured table not only includes values specifying the resources allocated for the initial PUSCH transmission. In addition, the RRC-configured table includes additional values K2' and / or SLIV' specifying the resources allocated for repetition of the initial PUSCH transmission. Furthermore, the optional additional value indicating the number of repetitions of at least one further complements the RRC-configured table in that it allows for more flexibility in determining which of the specified allocated resources to use for repetition.

[0337] In particular, in this sixth exemplary implementation, the table configured by the RRC comprises rows, each row including a value indicating a PUSCH mapping type, a value K2 indicating a slot offset for the first PUSCH transmission, a value SLIV indicating a start-length indicator for the first PUSCH transmission, and additional values a value K2' indicating a second slot offset for at least one repetition and a value SLIV' indicating a second start-length indicator value for at least one repetition.

[0338] Table 1 below reproduces an example of such a table configured by the RRC. [Table 1]

[0339] In this exemplary Table 1, the values SLIV and SLIV' are shown to include values S, S' indicating the symbol number that specifies the start of the allocated resource, and values L, L' indicating the number of symbols that specifies the length of the allocated resource, respectively.

[0340] In particular, this RRC configured table does not contain only one set of additional values K2′ and SLIV′ (or better K2′, S′, L′), but a set of such additional values for each PUSCH repetition transmitted by the user equipment 410. This achieves a high level of flexibility in each PUSCH repetition without incurring additional signaling overhead.

[0341] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH Time Domain Resource Allocation List IE, i.e., according to a list of parameters referred to as PUSCH time domain resource allocations. In other words, the table is defined by the PUSCH Time Domain Resource Allocation List IE conveyed in a PUSCH config IE received in RRC signaling.

[0342] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 6. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000010.jpg68170

[0343] As can be seen from this Example 6, the PUSCH time domain resource allocation parameters not only include a value indicating the PUSCH mapping type, a value K2 indicating the slot offset for the first PUSCH transmission, and a value SLIV indicating the start and length indicator for the first PUSCH transmission, but also a value indicating the number of repetitions (referred to as number of resource indicator value (RIV) allocations), a value K2' indicating a second slot offset for at least one repetition and a value SLIV' indicating a second start and length indicator value for at least one repetition, for each of the repetitions (referred to as RIV allocations).

[0344] Comparing the PUSCH time domain resource allocation list IE in Example 6 with the RRC configured table in Table 1, it can be seen that the value indicating the number of repetitions (referred to as the number of RIV allocations) in the IE is only reflected indirectly (i.e., in the form of the total number of values K2′, S′, and L′) in the RRC configured table, but this value can also be directly included in the RRC configured table.

[0345] Additional values are further detailed in connection with various uses of the sixth exemplary implementation depicted in FIGS.

[0346] [One Use of the Sixth Exemplary Implementation] The use of one of the RRC configured tables of the sixth exemplary implementation is depicted in Figures 13 and 14, which present an exemplary RRC configured table for PUSCH repetition using the sixth exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0347] According to this exemplary RRC configured table, values are presented in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0348] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0349] Furthermore, this line contains two additional values K2' indicating that the resources allocated for the first and second repetitions of the initial PUSCH transmission are contained in slots determined by the value k corresponding to the slot number carrying the received DCI or the value k corresponding to the value of the time domain offset field additionally carried in the received configured grant config IE.

[0350] Therefore, the allocated resources for the first and second repetitions are contained in slot number k+2 and slot number k+3, respectively. Two values S' and two values L' are further included, indicating that the allocated resources for the first and second repetitions of the initial PUSCH transmission start from symbol number 6 in slot number k+2 and symbol number 1 in slot number k+3, respectively. The respective resource allocations in the time domain are also shown.

[0351] Another Use of the Sixth Exemplary Implementation Another use of the RRC configured table of the sixth exemplary implementation is depicted in Figures 15 and 16, which present an exemplary RRC configured table for PUSCH repetition using the sixth exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0352] According to this exemplary RRC configured table, values are given in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0353] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0354] Furthermore, this row includes two additional values K2', which indicate that the resources allocated for both the first and second repetitions of the initial PUSCH transmission are included in a slot determined relative to slot number k+2, which includes the resources allocated for the initial PUSCH transmission.

[0355] Therefore, the resources allocated for the first and second repetitions are contained in slot (k+2)+0 and slot (k+2)+1, respectively. Two values S' and L' are further included, indicating that the resources allocated for the first and second repetitions of the initial PUSCH transmission start from symbol number 6 in slot (k+2)+0 and symbol number 1 in slot (k+2)+1, respectively. The respective resource allocations in the time domain are also shown.

[0356] Further Uses of the Sixth Exemplary Implementation Another use of the RRC configured table of the sixth exemplary implementation is depicted in Figures 17 and 18, which present an exemplary RRC configured table for PUSCH repetition using the sixth exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0357] According to this exemplary RRC configured table, values are given in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0358] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0359] Furthermore, this row includes two additional values K2', which indicate that the resources allocated for the first repetition of the first PUSCH transmission are included in the slot determined by slot number k+2 which contains the resources allocated for the first PUSCH transmission, and that the resources allocated for the second repetition are included in the slot determined by slot number (k+2)+1 which contains the resources allocated for the first repetition.

[0360] Thus, the allocated resources for the first and second repetitions are contained in slot number (k+2)+1 and slot number ((k+2)+1)+1, respectively. Furthermore, two values S' and two values L' are included, indicating that the allocated resources for the first and second repetitions of the initial PUSCH transmission start from symbol number 1 in slot number (k+2)+1 and from symbol number 1 in slot number ((k+2)+1)+1, respectively. The respective resource allocations in the time domain are also shown.

[0361] In other words, the second slot offset specifies the resources allocated for a subsequent one of the at least one repetition relative to the index of the slot containing the resources allocated for a preceding one of the at least one repetition.

[0362] [Seventh Exemplary Implementation] The following seventh exemplary implementation is conceived based on the understanding that the at least one additional value included in the indexed row of the table configured by the RRC is at least one of a value G' indicating the number of symbols of the gap before the resources allocated for the at least one repetition, a value L' indicating the number of symbols specifying the length of the resources allocated for the at least one repetition, and an optional value indicating the number of the at least one repetition.

[0363] According to the above understanding, the table configured by the RRC not only includes values specifying the resources allocated for the initial PUSCH transmission. In addition, the table configured by the RRC includes an additional value G' and / or a value L' specifying the resources allocated for the repetition of the initial PUSCH transmission. Furthermore, an optional additional value indicating the number of repetitions of at least one can further supplement the table configured by the RRC in allowing more flexibility in determining which of the specified allocated resources to use for the repetition.

[0364] Table 2 below reproduces an example of such a table configured by the RRC. [Table 2]

[0365] In particular, the table configured by the RRC does not contain only one set of additional values G' and L', but one additional value L' that applies to all repetitions and a set of additional values G' that are intended for each of the PUSCH repetitions transmitted by the user equipment 410. This achieves a high level of flexibility in each of the PUSCH repetitions without incurring additional signaling overhead.

[0366] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH Time Domain Resource Allocation List IE, i.e., according to a list of parameters referred to as PUSCH time domain resource allocations. In other words, the table is defined by the PUSCH Time Domain Resource Allocation List IE conveyed in a PUSCH config IE received in RRC signaling.

[0367] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 7. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000012.jpg67170

[0368] As can be seen from this Example 7, the PUSCH time domain resource allocation parameters not only include a value indicating the PUSCH mapping type, a value K2 indicating the slot offset for the first PUSCH transmission, and a value SLIV indicating the start-length indicator for the first PUSCH transmission, but also a value L' indicating the length of each repetition in number of symbols (called the length of each repetition), a value indicating the number of repetitions (called the number of repetitions), and a value G' indicating the number of symbols in the gap before the resources allocated for at least one repetition (called the repetition gap) for each of the repetitions.

[0369] Comparing the PUSCH time domain resource allocation list IE in Example 7 with the RRC configured table in Table 2, it can be seen that the value indicating the number of repetitions (referred to as Number of Repetitions) in the IE is only reflected indirectly (i.e., in the form of the total value G') in the RRC configured table, however, this value could also be included directly in the RRC configured table.

[0370] Additional values are further detailed in connection with various uses of the seventh exemplary implementation, depicted in FIGS.

[0371] [One Use of the Seventh Exemplary Implementation] The use of one of the RRC configured tables of the seventh exemplary implementation is depicted in Figures 19 and 20, which present an exemplary RRC configured table for PUSCH repetition using the seventh exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0372] According to this exemplary RRC configured table, values are given in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0373] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0374] Furthermore, this row includes one additional value L' indicating that the length, in number of symbols, of the allocated resources for each of the first and second repetitions is 4, and two additional values G' indicating that the allocated resources for the first and second repetitions of the initial PUSCH transmission start on symbols that include gaps G' of 1 and 6 symbols before the allocated resources.

[0375] For the first and second iterations, the number of symbols in the gap, indicated by the value G′, is referenced to the last symbol, number 4, in slot k+2 of the resources allocated for the first PUSCH transmission.

[0376] Therefore, the resources allocated for the first and second repetitions are included in the slot with slot number k+2. In particular, the last symbol number of the resources allocated for the first PUSCH transmission is 4. Therefore, a gap of one symbol determines that the resources allocated for the first repetition start at symbol number 4+1+1 and end at symbol number 4+1+1+4. A gap of six symbols determines that the resources allocated for the second repetition start at symbol number 4+6+1 and end at symbol number 4+6+1+4. The respective resource allocation in the time domain is also shown.

[0377] Another Use of the Seventh Exemplary Implementation Another use of the RRC configured table of the seventh exemplary implementation is depicted in Figures 21 and 22, which present an exemplary RRC configured table for PUSCH repetition according to another use of the seventh exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0378] According to this exemplary RRC configured table, values are given in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0379] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0380] The row further includes one additional value L' indicating that the length, in number of symbols, of the allocated resources for each of the first and second repetitions is 4, and two additional values G' indicating that the allocated resources for the first and second repetitions of the initial PUSCH transmission start at symbols that include a gap of 1 and 1 symbols before the allocated resources.

[0381] For the first repetition, the number of symbols in the gap indicated by the value G' is relative to the last symbol number in slot k+2 of the resources allocated for the first PUSCH transmission, which is 4. For the second repetition, the number of symbols in the gap indicated by the value G' is relative to the last symbol number in slot k+2 of the resources allocated for the first repetition, which is 4+1+4.

[0382] Therefore, the resources allocated for the first and second repetitions are included in the slot with slot number k+2. In particular, the last symbol number of the resources allocated for the first PUSCH transmission is 4. Therefore, a gap of one symbol determines that the resources allocated for the first repetition start at symbol number 4+1+1 and end at symbol number 4+1+4. Furthermore, a gap of one symbol determines that the resources allocated for the second repetition start at symbol number 4+1+4+1+1 and end at symbol number 4+1+4+1+4.

[0383] In other words, the number of symbols in the gap specifies the resources allocated for a subsequent one of the at least one repetition relative to the number of the last symbol of the resources allocated for a preceding one of the at least one repetition.

[0384] [Eighth Exemplary Implementation] The following eighth exemplary implementation is conceived based on the understanding that the at least one additional value included in the indexed row of the table configured by the RRC is at least one of a value G' indicating the number of symbols of the gap before the resources allocated for the at least one repetition, a value L' indicating the number of symbols specifying the length of the resources allocated for the at least one repetition, and an optional value indicating the number of the at least one repetition.

[0385] According to the above understanding, the table configured by the RRC not only includes values specifying the resources allocated for the initial PUSCH transmission. In addition, the table configured by the RRC includes an additional value G' and / or a value L' specifying the resources allocated for the repetition of the initial PUSCH transmission. Furthermore, an optional additional value indicating the number of repetitions of at least one can further supplement the table configured by the RRC in allowing more flexibility in determining which of the specified allocated resources to use for the repetition.

[0386] Table 3 below reproduces an example of such a table configured by the RRC. [Table 3]

[0387] In particular, the table configured by the RRC does not contain only one set of additional values G' and L', but a set of additional values G' and L' for each PUSCH repetition transmitted by the user equipment 410. This achieves a high level of flexibility in each PUSCH repetition without incurring additional signaling overhead.

[0388] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH Time Domain Resource Allocation List IE, i.e., according to a list of parameters referred to as PUSCH time domain resource allocations. In other words, the table is defined by the PUSCH Time Domain Resource Allocation List IE conveyed in a PUSCH config IE received in RRC signaling.

[0389] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 8. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000014.jpg68170

[0390] As can be seen from this Example 8, the PUSCH time domain resource allocation parameters not only include a value indicating the PUSCH mapping type, a value K2 indicating the slot offset for the first PUSCH transmission, and a value SLIV indicating the start-length indicator for the first PUSCH transmission, but also a value indicating the number of repetitions (referred to as Number of Repetitions), a value L' (referred to as Length of Repetition) indicating the length of each repetition in number of symbols for each of the repetitions (referred to as Repetition Gap), and a value G' indicating the number of symbols of the gap before the resources allocated for at least one repetition.

[0391] Comparing the PUSCH time domain resource allocation list IE in Example 8 with the RRC configured table in Table 3, it can be seen that the value indicating the number of repetitions (referred to as Number of Repetitions) in the IE is only reflected indirectly (i.e., in the form of the total number of values G' and L') in the RRC configured table, but this value can also be directly included in the RRC configured table.

[0392] Additional values are further detailed in connection with various uses of the eighth exemplary implementation depicted in FIGS.

[0393] [One Use of the Eighth Exemplary Implementation Form] The use of one of the RRC configured tables of the eighth exemplary implementation is depicted in Figures 23 and 24, which present an exemplary RRC configured table for PUSCH repetition using the eighth exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0394] According to this exemplary RRC configured table, values are given in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0395] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0396] Furthermore, the row contains two additional values L' and two additional values G', where the value L' indicates the length of the allocated resources for the first and second repetitions in number of symbols 4,3, and the value G' indicates that the allocated resources for the first and second repetitions of the initial PUSCH transmission start from symbols such that there is a gap G' of number of symbols 1,6 before the allocated resources.

[0397] For the first and second iterations, the number of symbols in the gap, indicated by the value G′, is referenced to the last symbol, number 4, in slot k+2 of the resources allocated for the first PUSCH transmission.

[0398] Therefore, the resources allocated for the first and second repetitions are included in the slot with slot number k+2. In particular, the last symbol of the resources allocated for the first PUSCH transmission is numbered 4. Therefore, a gap of one symbol determines that the resources allocated for the first repetition start at symbol number 4+1+1 and end at symbol number 4+1+4. A gap of six symbols determines that the resources allocated for the second repetition start at symbol number 4+6+1 and end at symbol number 4+6+3. The respective resource allocation in the time domain is also shown.

[0399] Another Use of the Eighth Exemplary Implementation Another use of the RRC configured table of the eighth exemplary implementation is depicted in Figures 25 and 26, which present an exemplary RRC configured table for PUSCH repetition according to another use of the eighth exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0400] According to this exemplary RRC configured table, values are given in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0401] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0402] Furthermore, this row contains two additional values L' and two additional values G', where the value L' indicates the length of the allocated resources for the first and second repetitions in number of symbols 4,3, and the value G' indicates that the allocated resources for the first and second repetitions of the initial PUSCH transmission start from a symbol such that there is a gap G' of number of symbols 1,1 before the allocated resources.

[0403] For the first repetition, the number of symbols in the gap indicated by the value G' is relative to the last symbol number in slot k+2 of the resources allocated for the first PUSCH transmission, which is 4. For the second repetition, the number of symbols in the gap indicated by the value G' is relative to the last symbol number in slot k+2 of the resources allocated for the first repetition, which is 4+1+4.

[0404] Therefore, the resources allocated for the first and second repetitions are included in the slot with slot number k+2. In particular, the last symbol number of the resources allocated for the first PUSCH transmission is 4. Therefore, a gap of one symbol determines that the resources allocated for the first repetition start at symbol number 4+1+1 and end at symbol number 4+1+4. Furthermore, a gap of one symbol determines that the resources allocated for the second repetition start at symbol number 4+1+4+1+1 and end at symbol number 4+1+4+1+3.

[0405] In other words, the number of symbols in the gap specifies the resources allocated for a subsequent one of the at least one repetition relative to the number of the last symbol of the resources allocated for a preceding one of the at least one repetition.

[0406] [Ninth exemplary implementation] The following ninth exemplary implementation is conceived based on the understanding that the at least one additional value included in the indexed row of the table configured by the RRC is at least one of a value L′ indicating the number of symbols specifying the length of the resources allocated for at least one repetition and an optional value indicating the number of at least one repetition.

[0407] According to the above understanding, the table configured by the RRC not only includes a value specifying the resources allocated for the initial PUSCH transmission. In addition, the table configured by the RRC includes an additional value L' specifying the resources allocated for the repetition of the initial PUSCH transmission. Furthermore, the optional additional value indicating the number of repetitions of at least one can further complement the table configured by the RRC in that it allows for more flexibility in determining which of the specified allocated resources to use for the repetition.

[0408] Table 4 below reproduces an example of such a table configured by the RRC. [Table 4]

[0409] In particular, the table configured by the RRC does not only contain one additional value L', but a set of additional values L' for each of the PUSCH repetitions transmitted by the user equipment 410. This achieves a high level of flexibility in each of the PUSCH repetitions without incurring additional signaling overhead.

[0410] In particular, the processor 430 of the user equipment 410 or the processor 480 of the base station 460 configures this table according to the parameters contained in the PUSCH Time Domain Resource Allocation List IE, i.e., according to a list of parameters referred to as PUSCH time domain resource allocations. In other words, the table is defined by the PUSCH Time Domain Resource Allocation List IE conveyed in a PUSCH config IE received in RRC signaling.

[0411] An example of such a PUSCH Time Domain Resource Allocation List IE is reproduced below, namely as Example 9. As terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000016.jpg65170

[0412] As can be seen from this Example 9, the PUSCH time domain resource allocation parameters not only include a value indicating the PUSCH mapping type, a value K2 indicating the slot offset for the first PUSCH transmission, and a value SLIV indicating the start-length indicator for the first PUSCH transmission, but also a value indicating the number of repetitions (referred to as number of repetitions) and, for each of the repetitions (referred to as repetition length), a value L' indicating the length of each of the at least one repetition in number of symbols (referred to as length of each repetition).

[0413] Comparing the PUSCH time domain resource allocation list IE in Example 9 with the RRC configured table in Table 4, it can be seen that the value indicating the number of repetitions (referred to as Number of Repetitions) in the IE is only reflected indirectly (i.e., in the form of the total value L') in the RRC configured table, however, this value could also be directly included in the RRC configured table.

[0414] Additional values are further detailed in connection with different uses of the ninth exemplary implementation depicted in FIGS.

[0415] [One Use of the Ninth Exemplary Implementation Form] The use of one of the RRC configured tables of the ninth exemplary implementation is depicted in Figures 27 and 28, which present an exemplary RRC configured table for PUSCH repetition using the ninth exemplary implementation, and also show the corresponding resource allocation in the time domain.

[0416] According to this exemplary RRC configured table, values are given in the row with row index 3, and the corresponding resource allocation in the time domain is also shown. The RRC configured table includes in the row with row index 3 a value indicating that the PUSCH mapping type is type b, which means that the resource allocation can start within the slot, and not necessarily at the beginning of the slot.

[0417] This row also includes a value K2, which indicates that the resources allocated for the first PUSCH transmission are included in slot k+2, and a value S and a value L, which indicate that the resources allocated for the first PUSCH transmission start with symbol number 1 in slot k+2 and have a length of 4 symbols.

[0418] Furthermore, this row contains two additional values L', which indicate the length of the allocated resources for the first and second repetitions in symbols 4,4.

[0419] For the first iteration, the start of the allocated resources consecutively follows the last symbol of the resources allocated for the first PUSCH transmission, and for the second iteration, the start of the allocated resources consecutively follows the last symbol of the resources allocated for the first iteration.

[0420] Therefore, the resources allocated for the first and second repetitions are included in the slot with slot number k+2. In particular, the last symbol number of the resources allocated for the first PUSCH transmission is 4. Therefore, the resources allocated for the first repetition are determined to start from symbol number 4+1 and end at symbol number 4+4. Furthermore, the resources allocated for the second repetition are determined to start from symbol number 4+4+1 and end at symbol number 4+4+4. The respective resource allocations in the time domain are also shown.

[0421] Further exemplary implementations Reference will now be made to further exemplary implementations, according to which the behavior of the first exemplary implementation or the second exemplary implementation can be configured in the base station 460. For this purpose, an exemplary PUSCH Time Domain Resource Allocation List IE can be specified below, namely as Example 10. As terminology may change in the future, this example shall be understood more broadly with regard to the functionality and concepts conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000017.jpg93170

[0422] In yet another example implementation, the PUSCH time domain resource allocation list IE further includes a parameter indicating whether the transport block size is calculated for each PUSCH transmission individually or whether a combined transport block size of all PUSCH transmissions (including the initial PUSCH transmission and at least one repetition thereof) is calculated.

[0423] This further exemplary implementation can be combined with any of the sixth to ninth exemplary implementations. When combined with the sixth exemplary implementation, an exemplary PUSCH Time Domain Resource Allocation List IE can be specified as follows, i.e., as reproduced in Example 11. Since terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts of conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000018.jpg70170

[0424] Importantly, Example 11 refers to two different calculation mechanisms for calculating the transport block size (TBS): a combined TBS calculation and an individual TBS calculation. However, this shall not be construed as a limitation on the present disclosure. Instead, those skilled in the art will readily appreciate that if agreement is reached to use three or more different calculation mechanisms, the applicable mechanism of the three or more different calculation mechanisms may be indicated via the PUSCH time domain resource allocation list IE.

[0425] In a further example implementation, the PUSCH time domain resource allocation list IE further includes a parameter indicating whether frequency hopping is applied individually for each PUSCH transmission or whether continuous frequency hopping is applied for all PUSCH transmissions (including the initial PUSCH transmission and at least one repetition thereof).

[0426] This further exemplary implementation can be combined with any of the sixth to ninth exemplary implementations. When combined with the sixth exemplary implementation, an exemplary PUSCH Time Domain Resource Allocation List IE can be specified as follows, i.e., as reproduced in Example 12. Since terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts of conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000019.jpg69170

[0427] Importantly, Example 12 refers to two different frequency hopping mechanisms (i.e., a mechanism in which frequency hopping is applied individually or a mechanism in which frequency hopping is applied to all PUSCH transmissions). However, this should not be construed as a limitation on the present disclosure. Instead, those skilled in the art will readily appreciate that if agreement is reached to use three or more different frequency hopping mechanisms, the applicable mechanism of the three or more different frequency hopping mechanisms may be indicated via the PUSCH time domain resource allocation list IE.

[0428] In yet another example implementation, the PUSCH time domain resource allocation list IE further includes a parameter indicating whether demodulation reference symbols (DMRS) are present in all or each respective repetition of the at least one repetition of the initial PUSCH transmission.

[0429] This further exemplary implementation can be combined with any of the sixth to ninth exemplary implementations. When combined with the sixth exemplary implementation, an exemplary PUSCH Time Domain Resource Allocation List IE can be specified as follows, i.e., as reproduced in Example 13. Since terminology may change in the future, this example shall be understood more broadly with respect to the functionality and concepts of conveying additional parameters included in the PUSCH Time Domain Resource Allocation List IE. JPEG0007720954000020.jpg73170

[0430] According to a first aspect, a user equipment (UE) includes: a receiver that, in operation, receives a Physical Uplink Shared Channel (PUSCH) config information element (IE) in the form of Radio Resource Control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, each row having a value indicative of a PUSCH mapping type, a value K2 indicative of a slot offset, and a value SLIV indicative of a start-length indicator; and the receiver, in operation, receives Downlink Control Information (DCI) in the form of Medium Access Control (MAC) signaling, conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures resources allocated for an initial PUSCH transmission and resources allocated for at least one repetition of the initial PUSCH transmission. and a transmitter for determining resources to be allocated to a PUSCH transmission based on a slot number carrying the received DCI and a value K2 indicating a slot offset and a value SLIV indicating a start-length indicator contained in an indexed row of an RRC-configured table, and for transmitting a PUSCH transmission using the determined allocated resources, respectively, for the initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission, wherein the determination of the allocated resources is based on at least one additional value contained in the indexed row of the RRC-configured table specifying time domain resources to be allocated for the at least one repetition of the initial PUSCH transmission.

[0431] According to a second aspect, a user equipment (UE) includes: a receiver that, in operation, receives a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, each row having a value indicative of a PUSCH mapping type, a value K2 indicative of a slot offset, and a value SLIV indicative of a start-length indicator; and the receiver, in operation, receives a Configured Grant Config IE in RRC signaling, conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures resources allocated for an initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission in accordance with the received Configured Grant Config IE. and a transmitter determining based on a value of a time domain offset field further conveyed in the IE and associated with the time domain resource allocation field, and a value K2 indicating a slot offset and a value SLIV indicating a start-length indicator contained in an indexed row of an RRC configured table, and in operation transmitting a PUSCH transmission using the determined allocated resources for the initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission, respectively, wherein the determination of the allocated resources is based on at least one additional value contained in the indexed row of the RRC configured table specifying the time domain resources to be allocated for the at least one repetition of the initial PUSCH transmission.

[0432] According to a third aspect provided in addition to the first or second aspect, the at least one additional value is one of a value K2' indicating a second slot offset for the at least one repetition, a value SLIV' indicating a second start-length indicator value for the at least one repetition, and a value indicating the number of the at least one repetition, and / or the second start-length indicator value SLIV' includes a value S' indicating a symbol number specifying the start of the resources allocated for the at least one repetition, and a value L' indicating a number of symbols specifying the length of the resources allocated for the at least one repetition.

[0433] According to a fourth aspect provided in addition to the second or third aspect, if the at least one additional value is a value K2′ indicating a second slot offset, the second slot offset specifies the allocated resources for all at least one repetition relative to the number of the slot carrying the received DCI or relative to the value of a time domain offset field further carried in the received configured grant config IE.

[0434] According to a fifth aspect provided in addition to the third or fourth aspect, if the at least one additional value is a value K2′ indicating a second slot offset, the second slot offset specifies the allocated resources for all of the at least one repetition relative to the number of the slot including the resources allocated for the first PUSCH transmission.

[0435] According to a sixth aspect provided in addition to the third or fourth aspect, if the at least one additional value is a value K2′ indicating a second slot offset, the second slot offset specifies resources allocated for a first repetition of the at least one repetition based on the slot number containing resources allocated for a first PUSCH transmission, or the second slot offset specifies resources allocated for a subsequent repetition of the at least one repetition based on the slot number containing resources allocated for a previous repetition of the at least one repetition.

[0436] According to a seventh aspect provided in addition to the first or second aspect, the at least one additional value is one of a value G' indicating the number of symbols of a gap before the resources allocated for the at least one repetition, a value L' indicating the number of symbols specifying the length of the resources allocated for the at least one repetition, and a value indicating the number of the at least one repetition.

[0437] According to an eighth aspect provided in addition to the seventh aspect, if the at least one additional value is a value G′ indicating a number of gap symbols, the number of gap symbols specifies the allocated resources for all at least one repetition relative to the number of the last symbol of the resources allocated for the first PUSCH transmission.

[0438] According to a ninth aspect provided in addition to the eighth aspect, if the at least one additional value is a value G' indicating a number of gap symbols, the number of gap symbols specifies the resources allocated for a first repetition of the at least one repetition based on the number of the last symbol of the resources allocated for the first PUSCH transmission, or the number of gap symbols specifies the resources allocated for a subsequent repetition of the at least one repetition based on the number of the last symbol of the resources allocated for a previous repetition of the at least one repetition.

[0439] According to a tenth aspect provided in addition to the third or eighth aspect, if the at least one additional value is a value L′ indicating a number of symbols specifying the length of the allocated resources, the number of symbols specifies the length of the allocated resources for all of the at least one repetition, or the number of symbols specifies the length of the allocated resources for each of the at least one repetition.

[0440] According to an eleventh aspect, which is provided in addition to one aspect of the first to tenth aspects, the PUSCH time domain resource allocation list IE further includes at least one of a parameter indicating whether a transport block size is calculated for each PUSCH transmission individually or a combined transport block size of all PUSCH transmissions, including the initial PUSCH transmission and its at least one repetition, is calculated; a parameter indicating whether frequency hopping is applied individually for each PUSCH transmission or whether successive frequency hopping is applied for all PUSCH transmissions, including the initial PUSCH transmission and its at least one repetition; and a parameter indicating whether demodulation reference symbols (DMRS) are present in all or each individual repetition of the at least one PUSCH transmission.

[0441] According to a twelfth aspect, a method for a UE includes receiving a Physical Uplink Shared Channel (PUSCH) config information element (IE) in form of Radio Resource Control (RRC) signaling, the PUSCH config IE being applicable to a specific bandwidth portion; configuring a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, each row having a value indicative of a PUSCH mapping type, a value K2 indicative of a slot offset, and a value SLIV indicative of a start-length indicator; receiving downlink control information (DCI) in form of medium access control (MAC) signaling, conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and configuring resources allocated for an initial PUSCH transmission and resources allocated for at least one repetition of the initial PUSCH transmission. determining resources to be allocated based on a slot number carrying the received DCI and a value K2 indicating a slot offset and a value SLIV indicating a start-length indicator contained in an indexed row of an RRC-configured table; and transmitting PUSCH transmissions using the determined allocated resources for the initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission, respectively, wherein the determination of the allocated resources is based on at least one additional value contained in the indexed row of the RRC-configured table specifying time domain resources to be allocated for the at least one repetition of the initial PUSCH transmission.

[0442] According to a thirteenth aspect, a method for a UE includes receiving a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a specific bandwidth portion; configuring a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator; receiving a configured grant config IE in RRC signaling, conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 for a table configured by the RRC; and configuring resources allocated for an initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission in the received configured grant config IE. determining based on a value of a time domain offset field further conveyed in the IE and associated with the time domain resource allocation field, and a value K2 indicating a slot offset and a value SLIV indicating a start-length indicator contained in an indexed row of an RRC configured table; and transmitting a PUSCH transmission using the determined allocated resources for the initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission, respectively, wherein the determination of the allocated resources is based on at least one additional value contained in the indexed row of the RRC configured table specifying the time domain resources to be allocated for the at least one repetition of the initial PUSCH transmission.

[0443] According to a fourteenth aspect, there is provided a base station (BS), comprising: a transmitter that, in operation, transmits a Physical Uplink Shared Channel (PUSCH) config information element (IE) in form of Radio Resource Control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE, the table comprising rows, each row having a value indicative of a PUSCH mapping type, a value K2 indicative of a slot offset, and a value SLIV indicative of a start-length indicator; and the transmitter, in operation, transmits downlink control information (DCI) in form of Medium Access Control (MAC) signaling, conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE, the table comprising rows, each row having a value indicative of a PUSCH mapping type, a value K2 indicative of a slot offset, and a value SLIV indicative of a start-length indicator. and a receiver configured to allocate resources based on a slot number of a slot carrying DCI to be transmitted, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator, contained in an indexed row of an RRC-configured table, and in operation receive a PUSCH transmission using the determined allocated resources for an initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission, respectively, wherein the determination of the allocated resources is based on at least one additional value contained in the indexed row of the RRC-configured table specifying time domain resources to be allocated for the at least one repetition of the initial PUSCH transmission.

[0444] According to a fifteenth aspect, a base station (BS) includes: a transmitter that, in operation, transmits a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE, the table comprising rows, each row having a value indicative of a PUSCH mapping type, a value K2 indicative of a slot offset, and a value SLIV indicative of a start-length indicator; and the transmitter, in operation, transmits, in RRC signaling, a configured grant config IE conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures resources for an initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission in the transmitted configured grant config IE. and a receiver configured to allocate resources based on a value of a time domain offset field further conveyed in the IE and associated with the time domain resource allocation field, and a value K2 indicating a slot offset and a value SLIV indicating a start-length indicator contained in an indexed row of an RRC configured table, and in operation receive a PUSCH transmission using the determined allocated resources for an initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission, respectively, wherein the determination of the allocated resources is based on at least one additional value contained in the indexed row of the RRC configured table specifying the time domain resources to be allocated for the at least one repetition of the initial PUSCH transmission.

[0445] According to a sixteenth aspect, a method in a base station (BS) includes the steps of: transmitting a Physical Uplink Shared Channel (PUSCH) config information element (IE) in form of Radio Resource Control (RRC) signaling, the PUSCH config IE being applicable to a specific bandwidth portion; configuring a table defined by a PUSCH Time Domain Resource Allocation List IE carried in the transmitted PUSCH config IE, the table comprising rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator; transmitting downlink control information (DCI) in form of Medium Access Control (MAC) signaling, carrying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the RRC-configured table; and configuring a number of slots carrying the transmitted DCI and a number of slots included in the indexed row of the RRC-configured table. and receiving a PUSCH transmission using the determined allocated resources for the first PUSCH transmission and for the at least one repetition of the first PUSCH transmission, respectively, wherein the determination of the allocated resources is based on at least one additional value included in an indexed row of a table configured by RRC, the indexed row specifying the time domain resources to be allocated for the at least one repetition of the first PUSCH transmission.

[0446] According to a seventeenth aspect, a method in a base station (BS) includes the steps of: transmitting a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a specific bandwidth portion; configuring a table defined by a PUSCH time domain resource allocation list IE carried in the transmitted PUSCH config IE, the table comprising rows, each row having a value indicating a PUSCH mapping type, a value K2 indicating a slot offset, and a value SLIV indicating a start-length indicator; transmitting a configured grant config IE in RRC signaling, carrying a time domain resource allocation field with value m, the value m providing a row index m+1 in the table configured by the RRC; and configuring the transmitted configured grant config IE in RRC signaling, the PUSCH config IE being applicable to a specific bandwidth portion. allocating resources for the initial PUSCH transmission and for at least one repetition of the initial PUSCH transmission based on a value of a time domain offset field further conveyed in the IE and associated with the time domain resource allocation field, and a value K2 indicating a slot offset and a value SLIV indicating a start-length indicator contained in an indexed row of an RRC configured table; and receiving PUSCH transmissions using the determined allocated resources for the initial PUSCH transmission and for the at least one repetition of the initial PUSCH transmission, respectively, wherein determining the allocated resources is based on at least one additional value contained in the indexed row of the RRC configured table specifying the time domain resources to be allocated for the at least one repetition of the first PUSCH transmission.

[0447] According to an eighteenth aspect, a user equipment (UE) includes: a receiver that, in operation, receives a physical uplink shared channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, at least one row including a first value set associated with time domain resources allocated for the multiple PUSCH transmissions; and the receiver, in operation, receives downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures the time domain resources allocated for the multiple PUSCH transmissions based on an index of a slot conveying the received DCI and a value of the assigned time domain resources. and a transmitter configured to determine a transport block of data to be carried in the plurality of PUSCH transmissions based on a first set of values included in an indexed row of an RRC-configured table associated with the PUSCH resource, the transport block of data being selected based on at least one second parameter included in the indexed row of the RRC-configured table, the at least one second parameter indicating whether the plurality of PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0448] According to a 19th aspect provided in addition to the 18th aspect, the same parameter among at least one second parameter (R, D) included in an indexed row of a table configured by the RRC indicates a different PUSCH transmission or a repeated PUSCH transmission for all of the multiple PUSCH transmissions.

[0449] According to a twentieth aspect provided in addition to the eighteenth aspect, different parameters of at least one second parameter included in an indexed row of a table configured by the RRC indicate different or repeated PUSCH transmissions for each of a plurality of PUSCH transmissions, except for a first PUSCH transmission of the plurality of PUSCH transmissions.

[0450] According to a 21st aspect provided in addition to the 18th to 20th aspects, the at least one second parameter is included in a PUSCH time domain resource allocation list IE.

[0451] According to a twenty-second aspect, a user equipment (UE) includes: a receiver that, in operation, receives a physical uplink shared channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, at least one row including a first value set associated with time domain resources allocated for a plurality of PUSCH transmissions; and the receiver, in operation, receives downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures the time domain resources allocated for the plurality of PUSCH transmissions based on a slot index conveying the received DCI and a time domain resource allocation list associated with the time domain resources allocated for a plurality of PUSCH transmissions. and a transmitter configured to determine based on a first set of values included in an indexed row of a table configured by RRC, the first set of values being associated with the allocated time domain resources, and configured, in operation, to select a transport block of data to be conveyed in the multiple PUSCH transmissions and transmit the multiple PUSCH transmissions respectively using the determined allocated time domain resources, wherein the transport block of data is selected based on at least one second parameter conveyed via received DCI signaling, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0452] According to a 23rd aspect provided in addition to the 22nd aspect, at least one second parameter is included in a dedicated bit field of the received DCI, and the same parameter of the at least one second parameter indicates a different PUSCH transmission or a repeated PUSCH transmission for all of the multiple PUSCH transmissions.

[0453] According to a 24th aspect provided in addition to the 22nd aspect, in operation, the receiver infers at least one second parameter from a specific Radio Network Temporary Identifier (RNTI) used to scramble a cyclic redundancy check (CRC) bit field of the received DCI, and the same inferred at least one second parameter indicates a different PUSCH transmission or a repeated PUSCH transmission for all of the multiple PUSCH transmissions.

[0454] According to a twenty-fifth aspect, a user equipment (UE) includes: a receiver that, in operation, receives a physical uplink shared channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, at least one row including a first value set associated with time domain resources to be allocated for the multiple PUSCH transmissions; and the receiver, in operation, receives downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures the time domain resources to be allocated for the multiple PUSCH transmissions based on an index of a slot conveying the received DCI and an index of a slot to be allocated. and a transmitter configured to determine based on a first set of values included in an indexed row of a table configured by RRC, the first set of values being associated with a time domain resource, and configured, in operation, to select a transport block of data to be conveyed in the plurality of PUSCH transmissions and transmit the plurality of PUSCH transmissions using the determined allocated time domain resource, wherein the transport block of data is selected based on at least one second parameter signaled via physical layer configuration signaling, the at least one second parameter indicating whether the plurality of PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0455] According to a 26th aspect provided in addition to the 25th aspect, in operation, a receiver receives at least one second parameter included in a Physical (Phy) Parameters IE in the form of RRC signaling, and the same at least one received second parameter indicates different or repeated PUSCH transmissions for all of a plurality of PUSCH transmissions.

[0456] According to a 27th aspect provided in addition to the 25th aspect, in operation, the receiver infers at least one second parameter from a radio frequency band setting of a specific bandwidth portion, and the same inferred at least one second value indicates different or repeated PUSCH transmissions for all of the multiple PUSCH transmissions.

[0457] According to a 28th aspect provided in addition to the 25th aspect, in operation, the receiver infers at least one second parameter from a service type setting having specific reliability and / or latency requirements, and the same inferred at least one second value indicates different or repeated PUSCH transmissions for all of the multiple PUSCH transmissions.

[0458] According to a 29th aspect, which is provided in addition to the 18th to 28th aspects, the determination of the allocated time domain resources is based on a first set of values included in each row of a table configured by the RRC, which is associated with the allocated time domain resources, and the first set of values includes a value indicating a PUSCH mapping type for at least a first PUSCH transmission of the plurality of PUSCH transmissions, a value K2 indicating a slot offset for at least a first PUSCH transmission of the plurality of PUSCH transmissions, and a value SLIV indicating a start-length indicator for at least a first PUSCH transmission of the plurality of PUSCH transmissions.

[0459] According to a 30th aspect, which is provided in addition to the 18th to 29th aspects, the determination of the allocated time domain resource is further based on at least one third value included in an indexed row of a table configured by the RRC, which is associated with the allocated time domain resource, and the at least one third value comprises at least one of a value K2' indicating another slot offset for a subsequent PUSCH transmission of the plurality of PUSCH transmissions, a value SLIV' indicating another start-length indicator value for a subsequent PUSCH transmission of the plurality of PUSCH transmissions, and a value indicating a total number of the plurality of PUSCH transmissions excluding the first PUSCH transmission of the plurality of PUSCH transmissions.

[0460] According to a 31st aspect provided in addition to the 30th aspect, another start-length indicator value SLIV' comprises a value S' indicating a symbol number specifying the start of resources allocated for a subsequent PUSCH transmission of the plurality of PUSCH transmissions, and a value L' indicating a number of symbols specifying the length of resources allocated for a subsequent PUSCH transmission of the plurality of PUSCH transmissions.

[0461] According to a 32nd aspect, which is provided in addition to the 18th to 31st aspects, the transmitter, in operation, further generates a plurality of PUSCH transmissions carrying selected transport blocks of data based on at least one fourth value further included in an indexed row of a table configured by an RRC associated with generating the plurality of PUSCH transmissions, wherein the at least one fourth value includes at least one of: a different modulation and coding scheme (MCS) index value for each of the plurality of PUSCH transmissions except for a first PUSCH transmission of the plurality of PUSCH transmissions, or the same modulation and coding scheme (MCS) index value for all of the plurality of PUSCH transmissions; and a different redundancy version (RV) offset value for each of the plurality of PUSCH transmissions except for the first PUSCH transmission of the plurality of PUSCH transmissions, or the same redundancy version (RV) offset value for all of the plurality of PUSCH transmissions.

[0462] According to a 33rd aspect, which is provided in addition to the 18th to 32nd aspects, the PUSCH time domain resource allocation list IE further includes at least one fifth parameter related to generation of the multiple PUSCH transmissions, the at least one fifth parameter including at least one of: a parameter indicating whether a transport block size is calculated individually for each of the multiple PUSCH transmissions or a combined transport block size of all PUSCH transmissions is calculated; a parameter indicating whether a modulation and coding scheme (MCS) index is determined individually for each of the multiple PUSCH transmissions or whether the same MCS index is determined for all PUSCH transmissions; a parameter indicating whether the same redundancy version (RV) is determined for all of the multiple PUSCH transmissions based on an RV field in the received DCI; and a parameter indicating whether a demodulation reference symbol (DMRS) is present in at least a first PUSCH transmission or all PUSCH transmissions of the multiple PUSCH transmissions.

[0463] According to a thirty-fourth aspect, a method for a UE includes receiving a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and configuring a table defined by a PUSCH Time Domain Resource Allocation List IE carried in an RRC-configured table, the table comprising rows, at least one row including a first set of values associated with time domain resources to be allocated for the multiple PUSCH transmissions; receiving downlink control information (DCI) signaling carrying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the RRC-configured table; determining the time domain resources to be allocated for the multiple PUSCH transmissions based on an index of a slot carrying the received DCI and the first set of values included in the indexed row of the RRC-configured table associated with the allocated time domain resources; selecting a transport block of data to be carried in the multiple PUSCH transmissions and transmitting the multiple PUSCH transmissions using the determined allocated time domain resources, respectively, wherein the transport block of data is selected based on at least one second parameter included in the indexed row of the RRC-configured table, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0464] According to a thirty-fifth aspect, a method for a UE includes receiving a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and configuring a table defined by a PUSCH Time Domain Resource Allocation List IE conveyed in a RRC configured table, the table comprising rows, and at least one row including a first set of values associated with time domain resources to be allocated for the multiple PUSCH transmissions; receiving downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the RRC configured table; determining the time domain resources to be allocated for the multiple PUSCH transmissions based on an index of a slot conveying the received DCI and the first set of values included in the indexed row of the RRC configured table associated with the allocated time domain resources; selecting transport blocks of data to be conveyed in the multiple PUSCH transmissions and transmitting the multiple PUSCH transmissions using the determined allocated time domain resources, respectively, wherein the transport blocks of data are selected based on at least one second parameter conveyed via the received DCI signaling, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0465] According to a thirty-sixth aspect, a method for a UE includes receiving a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and configuring a table defined by a PUSCH Time Domain Resource Allocation List IE signaled in a RRC-configured table, the table comprising rows, at least one row including a first set of values associated with time domain resources to be allocated for the multiple PUSCH transmissions; receiving downlink control information (DCI) signaling signaling a time domain resource allocation field having a value m, the value m providing a row index m+1 in the RRC-configured table; determining the time domain resources to be allocated for the multiple PUSCH transmissions based on an index of a slot carrying the received DCI and the first set of values included in the indexed row of the RRC-configured table associated with the allocated time domain resources; selecting transport blocks of data to be carried in the multiple PUSCH transmissions and transmitting the multiple PUSCH transmissions using the determined allocated time domain resources, respectively, wherein the transport blocks of data are selected based on at least one second parameter signaled via physical layer configuration signaling, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0466] According to a thirty-seventh aspect, a base station (BS) includes: a transmitter that, in operation, transmits a physical uplink shared channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE, the table comprising rows, at least one row including a first value set associated with time domain resources allocated for the multiple PUSCH transmissions; and the transmitter, in operation, transmits downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures the time domain resources for the multiple PUSCH transmissions based on an index of a slot conveying the transmitted DCI and the assigned time domain resources. and a receiver that, in operation, receives a plurality of PUSCH transmissions using the respective assigned time domain resources and processes a transport block of data carried in the plurality of received PUSCH transmissions, wherein the transport block of data is processed based on at least one second parameter included in the indexed row of the RRC-configured table, the at least one second parameter indicating whether the plurality of PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0467] According to a thirty-eighth aspect, a base station (BS) includes: a transmitter that, in operation, transmits a physical uplink shared channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE, the table comprising rows, at least one row including a first value set associated with time domain resources allocated for the multiple PUSCH transmissions; and the transmitter, in operation, transmits downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures the time domain resources for the multiple PUSCH transmissions based on an index of a slot conveying the transmitted DCI and the assigned time domain resource list. and a receiver that, during operation, receives a plurality of PUSCH transmissions using the respective assigned time domain resources and processes a transport block of data carried in the plurality of received PUSCH transmissions, wherein the transport block of data is processed based on at least one second parameter conveyed via transmitted DCI signaling, the at least one second parameter indicating whether the plurality of PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0468] According to a thirty-ninth aspect, a base station (BS) includes: a transmitter that, in operation, transmits a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; and a processor that, in operation, configures a table defined by a PUSCH time domain resource allocation list IE conveyed in the transmitted PUSCH config IE, the table comprising rows, at least one row including a first value set associated with time domain resources allocated for the multiple PUSCH transmissions; and the transmitter, in operation, transmits downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the table configured by the RRC; and the processor, in operation, configures the time domain resources for the multiple PUSCH transmissions based on a slot index conveying the transmitted DCI and a time domain resource allocation list IE associated with the time domain resources allocated for the multiple PUSCH transmissions. and a receiver that, in operation, receives a plurality of PUSCH transmissions using the time domain resources respectively assigned thereto and processes a transport block of data carried in the plurality of received PUSCH transmissions, wherein the transport block of data is processed based on at least one second parameter signaled via physical layer configuration signaling, the at least one second parameter indicating whether the plurality of PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0469] According to a fortieth aspect, a method of a base station includes the steps of transmitting a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; transmitting downlink control information (DCI) signaling carrying a time domain resource allocation field having a value m, the value m providing a row index m+1 in the RRC-configured table; allocating time domain resources for the multiple PUSCH transmissions based on an index of a slot carrying the transmitted DCI and the first set of values included in the indexed row of the RRC-configured table, the first set of values being associated with the allocated time domain resources; receiving the multiple PUSCH transmissions each using the assigned time domain resources; and processing a transport block of data carried in the multiple received PUSCH transmissions, wherein the transport block of data is processed based on at least one second parameter included in the indexed row of the RRC-configured table, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0470] According to a forty-first aspect, a method of a base station includes the steps of transmitting a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; transmitting downlink control information (DCI) signaling signaling a time domain resource allocation field having a value m, the value m providing a row index m+1 in the RRC-configured table; allocating time domain resources for the multiple PUSCH transmissions based on an index of a slot carrying the transmitted DCI and the first set of values included in the indexed row of the RRC-configured table that are associated with the allocated time domain resources; receiving the multiple PUSCH transmissions each using the assigned time domain resources; and processing a transport block of data carried in the multiple received PUSCH transmissions, wherein the transport block of data is processed based on at least one second parameter conveyed via the transmitted DCI signaling, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0471] According to a forty-second aspect, a method of a base station includes the steps of transmitting a Physical Uplink Shared Channel (PUSCH) config information element (IE) in radio resource control (RRC) signaling, the PUSCH config IE being applicable to a particular bandwidth portion; transmitting downlink control information (DCI) signaling signaling a time domain resource allocation field having a value m, the value m providing a row index m+1 in the RRC-configured table; allocating time domain resources for the multiple PUSCH transmissions based on an index of a slot carrying the transmitted DCI and the first set of values included in the indexed row of the RRC-configured table that are associated with the allocated time domain resources; receiving the multiple PUSCH transmissions each using the assigned time domain resources; and processing a transport block of data carried in the multiple received PUSCH transmissions, wherein the transport block of data is processed based on at least one second parameter signaled via the physical layer configuration signaling, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions.

[0472] The present disclosure can be implemented by software, by hardware, or by software in cooperation with hardware. Each functional block used in the description of each of the above-mentioned embodiments can be implemented in part or in whole by an LSI such as an integrated circuit, and each process described in each embodiment can be controlled in part or in whole by the same LSI or a combination of LSIs.

[0473] An LSI can be formed as an individual chip, or a single chip can be formed to contain some or all of the functional blocks. An LSI can include data input / output units coupled to it. Depending on the level of integration, an LSI is also called an IC, system LSI, super LSI, or ultra LSI.

[0474] However, the technique for implementing the integrated circuit is not limited to LSI, but can be implemented by using dedicated circuitry, general-purpose processors, or dedicated processors.

[0475] Furthermore, it is also possible to use FPGAs (field programmable gate arrays), which can be programmed after the LSI is manufactured, and reconfigurable processors, which allow the connections and settings of circuit cells placed inside the LSI to be reconfigured.

[0476] The present disclosure can be implemented as digital processing or analog processing. As a result of advances in semiconductor technology or other derivative technologies, if LSI is replaced by future integrated circuit technology, the future integrated circuit technology can be used to integrate the functional blocks. Biotechnology can also be applied.

[0477] The present disclosure can be implemented by any kind of apparatus, device, or system having a communication capability (referred to as a communication apparatus).

[0478] Some non-limiting examples of such communications devices include telephones (e.g., mobile phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, e-readers, telehealth / telemedicine devices, vehicles (e.g., automobiles, airplanes, ships) that provide communications capabilities, and various combinations thereof.

[0479] The communications apparatus is not limited to portable or mobile, but can also include any type of apparatus, device, or system that is non-portable or stationary, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "thing" in an "Internet of Things" network.

[0480] Communication can include exchanging data, for example, through cellular systems, wireless LAN systems, satellite systems, etc., and various combinations thereof.

[0481] The communications apparatus may include devices such as controllers and sensors coupled to the communications device to perform the communications functions described in this disclosure. For example, the communications apparatus may include a controller or sensor that generates control or data signals used by the communications device to perform the communications functions of the communications apparatus.

[0482] The communications apparatus may further include infrastructure facilities, such as base stations, access points, and any other apparatus, device, or system that communicate with or control apparatuses such as the apparatuses in the non-limiting examples above.

Claims

1. A communication system including a user equipment (UE) and a base station, The user equipment: a receiver configured to receive a Physical Uplink Shared Channel (PUSCH) config information element (IE) in the form of Radio Resource Control (RRC) signaling, the PUSCH config IE being applicable to a specific bandwidth portion; a processor for configuring a table defined by a PUSCH time domain resource allocation list information element (IE) conveyed in the received PUSCH config IE, the table comprising rows, at least one row including a first set of values associated with time domain resources allocated for multiple PUSCH transmissions; and the receiver receives downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, and a row included in the RRC configured table is indexed by an index m+1 based on the value m; The processor determines time domain resources allocated for the plurality of PUSCH transmissions based on an index of a slot carrying the received DCI and the first set of values included in a row indicated by the index of the RRC-configured table associated with the allocated time domain resources; a transmitter configured to select a transport block of data to be carried in the plurality of PUSCH transmissions and to transmit the plurality of PUSCH transmissions using the determined allocated time domain resources, respectively; Equipped with The base station a base station side transmitter that transmits the Physical Uplink Shared Channel (PUSCH) config information element (IE) in the form of the Radio Resource Control (RRC) signaling; a base station side receiver configured to receive the plurality of PUSCH transmissions using the time domain resources; Equipped with the transport block of data is selected based on at least one second parameter included in a row indicated by the index of a table configured by the RRC, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions; Communication system.

2. The same parameter among the at least one second parameter (R, D) included in the row indicated by the index of the table configured by the RRC indicates a different PUSCH transmission or a repeated PUSCH transmission for all of the plurality of PUSCH transmissions. or a different parameter among the at least one second parameter included in a row indicated by the index of the table configured by the RRC indicates a different or repeated PUSCH transmission for each of the plurality of PUSCH transmissions, except for a first PUSCH transmission of the plurality of PUSCH transmissions; The communication system of claim 1 .

3. the transport block of data is selected based on at least one second parameter signaled via physical layer configuration signaling, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions; The communication system of claim 1 .

4. The receiver receives the at least one second parameter included in a physical (Phy) parameter information element (IE) in the form of RRC signaling, and the same received at least one second parameter indicates a different or repeated PUSCH transmission for all of the plurality of PUSCH transmissions. or the receiver infers the at least one second parameter from a radio frequency band setting of the specific bandwidth portion, and the same inferred at least one second value indicates a different or repeated PUSCH transmission for all of the plurality of PUSCH transmissions. or the receiver infers the at least one second parameter from a service type configuration having a specific reliability requirement and / or latency requirement, and the same inferred at least one second value indicates a different or repeated PUSCH transmission for all of the plurality of PUSCH transmissions; The communication system according to claim 3 .

5. The determination of the assigned time domain resources is based on the first value set included in each row of a table configured by the RRC associated with the assigned time domain resources, and the first value set is a value indicating a PUSCH mapping type for at least a first PUSCH transmission of the plurality of PUSCH transmissions; a value K indicating a slot offset for at least a first PUSCH transmission of the plurality of PUSCH transmissions; ２ , and a value SLIV indicating a start-length indicator for at least a first PUSCH transmission of the plurality of PUSCH transmissions; Including, The communication system of claim 1 .

6. The determination of the assigned time domain resources is further based on at least one third value included in a row indicated by the index of a table configured by the RRC related to the assigned time domain resources, and the at least one third value is a value K 2 ′ indicating another slot offset for a subsequent PUSCH transmission of the plurality of PUSCH transmissions; a value SLIV′ indicating another Start Length Indicator Value for a subsequent PUSCH transmission of the plurality of PUSCH transmissions; and a value indicating the total number of the plurality of PUSCH transmissions, excluding the first PUSCH transmission of the plurality of PUSCH transmissions; and said further start-length indicator value SLIV' being: a value S′ indicating a symbol number specifying the start of resources allocated for a subsequent PUSCH transmission of the plurality of PUSCH transmissions, and a value L′ indicating a number of symbols specifying the length of resources allocated for subsequent PUSCH transmissions of the plurality of PUSCH transmissions, Including, The communication system of claim 1 .

7. the transmitter generates the plurality of PUSCH transmissions carrying the selected transport blocks of data based on at least one fourth value included in a row indicated by the index of the RRC-configured table associated with generation of the plurality of PUSCH transmissions, the at least one fourth value being: a different modulation and coding scheme (MCS) index value for each of the plurality of PUSCH transmissions, except for a first PUSCH transmission of the plurality of PUSCH transmissions; or the same modulation and coding scheme (MCS) index value for all of the plurality of PUSCH transmissions; Including, The communication system of claim 1 .

8. The method of claim 7, wherein the transmitter further generates the plurality of PUSCH transmissions carrying the selected transport blocks of data based on at least one fourth value further included in a row indicated by the index of a table configured by the RRC associated with generating the plurality of PUSCH transmissions, the at least one fourth value being: a different redundancy version (RV) offset value for each of the plurality of PUSCH transmissions, except for a first PUSCH transmission of the plurality of PUSCH transmissions; or the same redundancy version (RV) offset value for all of the plurality of PUSCH transmissions; Including, The communication system of claim 1 .

9. The PUSCH time domain resource allocation list IE further includes at least one fifth parameter related to the generation of the plurality of PUSCH transmissions, the at least one fifth parameter being: a parameter indicating whether a transport block size is calculated for each of the multiple PUSCH transmissions individually or whether a combined transport block size of all PUSCH transmissions is calculated; a parameter indicating whether a modulation and coding scheme (MCS) index is determined individually for each of the plurality of PUSCH transmissions or whether the same MCS index is determined for all PUSCH transmissions; and a parameter indicating whether the same redundancy version (RV) is determined for all of the plurality of PUSCH transmissions based on the RV field in the received DCI; at least one of The communication system according to claim 7.

10. 1. A method of a communication system including a user equipment (UE) and a base station, comprising: receiving, by the user equipment, a Physical Uplink Shared Channel (PUSCH) config information element (IE) in the form of Radio Resource Control (RRC) signaling, the PUSCH config IE being applicable to a specific bandwidth portion; configuring, by the user equipment, a table defined by a PUSCH time domain resource allocation list IE conveyed in the received PUSCH config IE, the table comprising rows, at least one row including a first set of values associated with time domain resources allocated for multiple PUSCH transmissions; receiving, by the user equipment, downlink control information (DCI) signaling conveying a time domain resource allocation field having a value m, wherein a row included in a table configured by the RRC is indicated by an index m+1 that is based on m; determining, by the user equipment, time domain resources to be allocated for the multiple PUSCH transmissions based on an index of a slot carrying the received DCI and the first set of values contained in a row indicated by the index of the RRC configured table associated with the allocated time domain resources; selecting, by the user equipment, transport blocks of data to be carried in the plurality of PUSCH transmissions and transmitting the plurality of PUSCH transmissions using the determined allocated time domain resources, respectively; transmitting, by the base station, the Physical Uplink Shared Channel (PUSCH) config information element (IE) in the Radio Resource Control (RRC) signaling; receiving, by the base station, the plurality of PUSCH transmissions using the time domain resources; Including, the transport block of data is selected based on at least one second parameter included in a row indicated by the index of a table configured by the RRC, the at least one second parameter indicating whether the multiple PUSCH transmissions are different PUSCH transmissions or repeated PUSCH transmissions; method.

Images