Processing time relaxation

Abstract

Embodiments of the present disclosure relate to processing time relaxation. The terminal device determines that the processing time is insufficient to prepare uplink transmissions to the network device. Then, the terminal device notifies the network device that the processing time is insufficient. Thus, system overhead can be avoided, additional cost savings can be enabled, and transmission efficiency can be improved.

Description

Technical Field

[0001] Various example embodiments relate to the field of telecommunications, and in particular to methods, devices, apparatus, and computer-readable storage media for handling temporal relaxation. Background Art

[0002] In communication technology, there is an ongoing evolution to provide efficient and reliable solutions for utilizing wireless communication networks. Currently, efforts are underway to develop fifth-generation (5G) or 5G-advanced wireless systems. The new wireless systems can support various types of service applications for terminal devices.

[0003] In current wireless systems, to promote complexity reduction and thereby save power consumption, reduced capability (RedCap) (and its enhanced version (e.g., eRedCap)) user equipment (UE) has been proposed. Compared to traditional UEs, RedCap UEs are configured with lower capabilities, for example, in terms of device bandwidth, antenna configuration, downlink multiple-input multiple-output (MIMO) support, duplex operation, maximum modulation, peak data rate, etc. However, there are still some open issues for RedCap UEs that will be studied in the near future. Summary of the Invention

[0004] Generally speaking, example embodiments of the present disclosure provide solutions related to processing time relaxation.

[0005] In a first aspect, a terminal device is provided. The terminal device includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device to at least: determine that processing time is insufficient to prepare an uplink transmission to a network device; and notify the network device of the insufficient processing time.

[0006] In a second aspect, a network device is provided. The network device includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the network device to at least: determine, based on communicating with a terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; and receive an uplink transmission from the terminal device based on a second processing time sufficient for the terminal device to prepare the uplink transmission.

[0007] In a third aspect, a method implemented at a terminal device is provided, comprising: determining that processing time is insufficient to prepare an uplink transmission to a network device; and notifying the network device of the insufficient processing time.

[0008] In a fourth aspect, a method implemented at a network device is provided, the method comprising: determining, based on communicating with a terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; and receiving an uplink transmission from the terminal device based on a second processing time sufficient for the terminal device to prepare the uplink transmission.

[0009] In a fifth aspect, an apparatus is provided. The apparatus includes: means for determining at a terminal device that processing time is insufficient to prepare an uplink transmission to a network device; and means for notifying the network device of the insufficient processing time.

[0010] In a sixth aspect, an apparatus is provided. The apparatus comprises: means for determining, at a network device based on communicating with a terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; and means for receiving an uplink transmission from the terminal device based on a second processing time sufficient for the terminal device to prepare the uplink transmission.

[0011] In a seventh aspect, a non-transitory computer-readable medium including program instructions is provided, the program instructions being used to cause an apparatus to at least execute the method according to any one of the third to fourth aspects above.

[0012] In an eighth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, causes the apparatus to at least perform the method according to any one of the third to fourth aspects above.

[0013] In a ninth aspect, a terminal device is provided, comprising: a determination circuit system configured to determine that processing time is insufficient to prepare an uplink transmission to a network device; and a notification circuit system configured to notify the network device of the insufficient processing time.

[0014] In a tenth aspect, a network device is provided. The network device includes: determining circuitry configured to determine, based on communicating with a terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; and receiving circuitry configured to receive an uplink transmission from the terminal device based on a second processing time sufficient for the terminal device to prepare the uplink transmission.

[0015] It should be understood that the invention summary is not intended to identify the key or essential features of the embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0017] Figure 1A illustrates an example environment in which example embodiments of the present disclosure may be implemented;

[0018] Figure 1B and Figure 1C UE processing times associated with scheduling DL and UL transmission cases, respectively, according to some example embodiments of the present disclosure;

[0019] Figure 2 illustrates a signaling flow between a terminal device and a network device according to some example embodiments of the present disclosure;

[0020] Figure 3 illustrates a first example communication process between a UE and a gNB according to some example embodiments of the present disclosure;

[0021] Figure 4 illustrates a second example communication procedure between a UE and a gNB according to some example embodiments of the present disclosure;

[0022] Figure 5 illustrates a third example communication procedure between a UE and a gNB according to some example embodiments of the present disclosure;

[0023] Figure 6 illustrates a fourth example communication procedure between a UE and a gNB according to some example embodiments of the present disclosure;

[0024] Figure 7 illustrates a fifth example communication procedure between a UE and a gNB according to some example embodiments of the present disclosure;

[0025] Figure 8 A flowchart of a method implemented at a terminal device according to some embodiments of the present disclosure is illustrated;

[0026] Figure 9 A flowchart illustrating a method implemented at a network device according to some embodiments of the present disclosure is illustrated;

[0027] Figure 10 illustrates a simplified block diagram of a device suitable for implementing some example embodiments of the present disclosure; and

[0028] Figure 11 A block diagram illustrating an example of a computer-readable medium according to some example embodiments of the present disclosure is illustrated.

[0029] Throughout the drawings, the same or similar reference numerals represent the same or similar elements. DETAILED DESCRIPTION

[0030] The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described for illustrative purposes and to help those skilled in the art understand and implement the present disclosure, without representing any limitation on the scope of the present disclosure. The present disclosure described herein can be implemented in various ways in addition to the ways described below.

[0031] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0032] References in this disclosure to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment will necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases are not necessarily referring to the same embodiment. In addition, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, those skilled in the art recognize that it is within the knowledge of those skilled in the art to incorporate such feature, structure, or characteristic in conjunction with other embodiments (whether or not explicitly described).

[0033] It should be understood that although the terms "first" and "second" etc. can be used to describe various elements in this article, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the example embodiments, the first element can be referred to as the second element, and similarly, the second element can be referred to as the first element. As used in this article, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0034] The term used in this article is used to describe the purpose of specific embodiment, and is not intended to limit example embodiment.As used in this article, singular form " one ", " one " and " the " are also intended to include plural form, unless context clearly indicates otherwise.It will also be understood that the terms " include ", " comprise ", " have ", " have ", " include " and / or " include " specify the existence of described feature, element and / or component etc. when used in this article, but do not exclude the existence or addition of one or more other features, elements, components and / or their combination.As used in this article, " at least one of the following items: < list of two or more elements > " and " at least one of < list of two or more elements > " and similar wording (wherein the list of two or more elements is connected by " and " or ") represent at least any one element, or at least any two or more elements, or at least all elements.

[0035] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0036] (a) hardware circuit implementation only (such as implementation only in analog and / or digital circuitry); and

[0037] (b) a combination of hardware circuitry and software such as (where applicable):

[0038] (i) a combination of analog and / or digital hardware circuits and software / firmware, and

[0039] (ii) any portion of the hardware processor(s) with software (including

[0040] digital signal processor(s), software, and memory(s), which work together to enable a device (such as a mobile phone or server) to perform various functions) and

[0041] (iii) hardware circuit(s) and or processor(s), such as microprocessor(s) or portion(s) of microprocessor(s), which require software (e.g. firmware) to operate, but in which case the software may not be present when not required for operation.

[0042] This definition of circuitry applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. For example, if applicable to a particular claim element, the term circuitry also covers a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device.

[0043] As used herein, the term "communication network" refers to a network that complies with any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), Advanced LTE (LTE-A), Wideband Code Division Multiple Access (WCDMA), High Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. In addition, the communication between the terminal equipment and the network equipment in the communication network can be performed according to any suitable intergenerational communication protocol, including but not limited to, third generation (3G), fourth generation (4G), 4.5G, fifth generation communication protocol (5G), and / or any other protocol currently known or to be developed in the future. The embodiments of the present disclosure can be applied to various communication systems. Due to the rapid development of communication, there will certainly be future types of communication technologies and systems that utilize them to implement the present disclosure. It should not be regarded as limiting the scope of the present disclosure to the above-mentioned systems.

[0044] As used herein, the term "network device" refers to a node in a communication network via which a terminal device accesses the network and receives services from it. A network device may refer to a base station (BS) or an access point (AP), for example, a NodeB (NodeB or NB), an evolved NodeB (eNodeB or eNB), a new radio (NR) NB (also known as a gNB), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, a low-power node (such as a femto, pico, etc.), depending on the terminology and technology of the application.

[0045] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS) or access terminal (AT). Terminal devices may include, but are not limited to, mobile phones, cellular phones, smart phones, voice over IP (VoIP) phones, wireless local loop phones, tablet computers, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), game terminal devices, music storage and playback devices, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop devices (LMEs), USB dongles, smart devices, wireless customer premises equipment (CPEs), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

[0046] The principles and embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Figure 1A , which illustrates an example environment 100 in which example embodiments of the present disclosure may be implemented.

[0047] The environment 100 may be part of a communication network and includes an end device 110 and a network device 120 that communicate with each other or with other devices via each other.

[0048] The communication environment 100 may include any suitable number of devices and cells. In the communication environment 100, the terminal device 110 and the network device 120 may communicate data and control information to each other. The link from the network device 120 to the terminal device 110 is called the downlink (DL), while the link from the terminal device 110 to the network device 120 is called the uplink (UL).

[0049] It should be understood that the two devices shown in environment 100 are for illustration purposes and are not intended to limit the scope of the present disclosure. In some example embodiments, environment 100 may include additional devices that communicate with terminal device 110 and network device 120.

[0050] Communications in environment 100 may follow any suitable communication standards or protocols that already exist or will be developed in the future, such as Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), LTE-Advanced (LTE-A), Fifth Generation (5G) New Radio (NR), Wireless Fidelity (Wi-Fi), and Worldwide Interoperability for Microwave Access (WiMAX) standards, and employ any suitable communication technology, including, for example, Multiple Input Multiple Output (MIMO), Orthogonal Frequency Division Multiplexing (OFDM), Time Division Multiplexing (TDM), Frequency Division Multiplexing (FDM), Code Division Multiplexing (CDM), Bluetooth, Zigbee, and Machine Type Communication (MTC), Enhanced Mobile Broadband (eMBB), Massive Machine Type Communication (mMTC), Ultra-Reliable Low Latency Communication (URLLC), Carrier Aggregation (CA), Dual Connectivity (DC), and New Radio Unlicensed (NR-U) technologies.

[0051] As mentioned above, in order to promote complexity reduction and thus save power consumption, RedCap UE has been proposed. In Release 17 (Rel-17), the 3rd Generation Partnership Project (3GPP) has specified RedCap UE with the following capabilities as shown in Table 1.

[0052] Table 1: NR devices with reduced capabilities.

[0053]

[0054]

[0055] In Release 18 (Rel-18), 3GPP also specifies a reduction in device complexity in Frequency Range 1 (FR1). The goal is to introduce a low-layer device between massive IoT and Rel-17 RedCap devices. The peak data rate supported by new Rel-18 devices is expected to be approximately 10 Mbps. Work item description RP-223544 includes the following objectives:

[0056]

[0057]

[0058] The inventors have observed that when bandwidth is limited to 5 MHz and processing time is relaxed, a complexity reduction of about 20-25% is possible for Rel-17 devices. In the Rel-18 eRedCap study project, processing time relaxation is proposed as a candidate for reducing UE complexity. More details on processing time are given in the Figure 1B and Figure 1C Let’s discuss.

[0059] Figure 1B and Figure 1C UE processing times associated with scheduling DL and UL transmission cases according to some example embodiments of the present disclosure are shown respectively.The two UE processing times associated with scheduling are described in Technical Specification (TS) 38.214.

[0060] The UE processing time associated with scheduled DL transmissions is used to prepare for hybrid automatic repeat request (HARQ) feedback for the physical downlink shared channel (PDSCH). The UE processing time associated with scheduled DL transmissions is associated with the PDSCH-to-HARQ-feedback timing indicator field. The UE processing time associated with scheduled DL transmissions is associated with parameter K1 as described in TS 38.214 Section 5.3. The UE processing time associated with scheduled UL transmissions is used to prepare for transmissions on the physical uplink shared channel (PUSCH). The UE processing time associated with scheduled UL transmissions is associated with time domain resource allocation. The UE processing time associated with scheduled UL transmissions is associated with the slot offset parameter K2 as described in TS 38.214 Section 6.1.2.1. Parameters K1 and K2 depend on parameter N1 (see Tables 5.3-1 and 5.3.2 in TS 38.214 Section 5.3) and parameter N2 (see TS 38.214 Section 6.4). Parameters K1 and K2 and their relationship with parameters N1 and N2 are respectively Figure 1B and Figure 1C Middle picture.

[0061] like Figure 1B As shown, the UE processing time T associated with scheduling DL transmission depends on the parameter N1. proc,1 Expressed as:

[0062] T proc,1 =(N1+d 1，1 +d2)(2048+144)·κ2 -μ ·T C +Text

[0063] The descriptions of the above parameters are as follows:

[0064] - N1 is based on μ from Table 5.3-1 and Table 5.3-2 for UE processing capabilities 1 and 2, respectively, where μ corresponds to the maximum T proc，1 The obtained (μ PDCCH , μ PDSCH , μ UL ), where μ PDCCH The subcarrier spacing of the PDCCH corresponding to the scheduling of PDSCH, μ PDSCH corresponds to the subcarrier spacing of the scheduled PDSCH, and μ UL The subcarrier spacing corresponding to the uplink channel with which HARQ-ACK is assumed to be sent, regardless of whether PDSCH reception provides transport blocks for a HARQ process with disabled HARQ-ACK information, as indicated by HARQ-feedbackEnabling-disablingperHARQprocess (if provided), and κ is defined in section 4.1 of [4, TS 38.211].

[0065] - For operation in FR1 with shared spectrum channel access, T ext is calculated according to [4, TS 38.211], otherwise T ext =0.

[0066] - If the position l1 of the PDSCH DM-RS for the additional DM-RS in Table 7.4.1.1.2-3 in Section 7.4.1.1.2 of [4, TS 38.211] is l1=12, then in Table 5.3-1, N 1，0 =14, otherwise N 1，0 =13.

[0067] - If the UE is configured with multiple active component carriers, the first uplink symbol carrying HARQ-ACK information also includes the effect of the timing difference between the component carriers as given in [11, TS 38.133].

[0068] - For PDSCH mapping type A as given in clause 7.4.1.1 of [4, TS 38.211]: If the last symbol of the PDSCH is on the i-th symbol of the slot, where i<7, then d 1，1 =7-i, otherwise d 1，1 =0.

[0069] - If a physical uplink control channel (PUCCH) of a larger priority index overlaps with a PUCCH / PUSCH of a smaller priority index, d2 for the PUCCH of the larger priority is set to be reported by the UE, otherwise d2 = 0.

[0070] - For UE processing capability 1: If PDSCH is mapping type B as given in clause 7.4.1.1 of [4, TS 38.211], and

[0071] - If the number of allocated PDSCH symbols is L ≥ 7, then d 1，1 =0,

[0072] - If the number of allocated PDSCH symbols is L≥4 and L≤6, then d 1，1 =7-L.

[0073] - If the number of allocated PDSCH symbols is L=3, then d 1,1 =3+min(d,1), where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH.

[0074] - If the number of allocated PDSCH symbols is 2, then d 1,1 =3+d, where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH.

[0075] - For UE processing capability 2: If PDSCH is mapping type B as given in clause 7.4.1.1 of [4, TS 38.211],

[0076] - If the number of allocated PDSCH symbols is L ≥ 7, then d 1，1 =0,

[0077] - If the number of allocated PDSCH symbols is L≥4 and L≤6, then d 1,1 is the number of overlapping symbols of scheduled PDCCH and scheduled PDSCH,

[0078] -If the number of allocated PDSCH symbols is 2,

[0079] - If the scheduled PDCCH is in a 3-symbol CORESET and the CORESET and PDSCH have the same starting symbol, then d 1，1 =3,

[0080] - Otherwise d 1，1 is the number of overlapping symbols of scheduled PDCCH and scheduled PDSCH.

[0081] like Figure 1CAs shown, the UE processing time T associated with scheduling UL transmission depends on the parameter N2. proc，2 Expressed as:

[0082] T proc,2 =max((N2+d 2,1 +d2)(2048+144);κ2 -μ ·T C +T ext +T switch ,d 2,2 ) The descriptions of the above parameters are as follows:

[0083] - N2 is μ based on Table 6.4-1 and Table 6.4-2 for UE processing capabilities 1 and 2, respectively, where μ corresponds to utilizing the maximum T proc，2 The obtained (μ UL , μ DL ), where μ DL The PDCCH carrying downlink control information (DCI) for scheduling the PUSCH is transmitted using the subcarrier spacing corresponding to the downlink, and μ UL corresponds to the subcarrier spacing of the uplink channel with which the PUSCH will be transmitted, and κ is defined in [4, TS 38.211] clause 4.1.

[0084] -For shared spectrum channel access operations, T ext is calculated according to [4, TS 38.211], otherwise T ext =0.

[0085] If the first symbol of the PUSCH allocation includes only DM-RS, then d 2,1 =0, otherwise d 2,1 =1.

[0086] - If the UE is configured with multiple active component carriers, the first uplink symbol in the PUSCH allocation also includes the effect of the timing difference between the component carriers as given in [11, TS 38.133].

[0087] - If the DCI is scheduled to trigger the switching of BWP, then d 2,2 is equal to the switching time as defined in [11, TS 38.133], otherwise d 2，2 =0.

[0088] - If a PUSCH with a larger priority index overlaps with a PUCCH with a smaller priority index, d2 for the PUSCH with the larger priority is set to be reported by the UE, otherwise d 2，2 =0.

[0089] - If the uplink switching gap is triggered as defined in clause 6.1.6, then T switch Equal to the switching gap duration and, for UEs configured with the higher layer parameter uplinkTxSwitchingOption, set to the value used for uplink carrier aggregation μ UL =min(μ UL,carrier1 , μ UL,carrier2 ), "dualUL", otherwise T switch =0.

[0090] In Rel-17, the legacy UE processing time for N1 and N2 is shown as follows:

[0091] N1 - 8, 10, 17 and 20 symbols for 15, 30, 60 and 120KHz SCS

[0092] N2 - 10, 12, 23, and 36 symbols for 15, 30, 60, and 120 KHz SCS

[0093] In the Rel-18eRedCap (i.e., Rel-18 enhanced support for reduced-capability NR devices) study project, a significant relaxation of N1 / N2 is proposed to reduce UE complexity. During the evaluation phase, the proposed values ​​for this study are as follows:

[0094] N1 - 16, 20, 34 and 40 symbols for 15, 30, 60 and 120KHz SCS

[0095] N2 - 20, 24, 46, and 72 symbols for 15, 30, 60, and 120 KHz SCS

[0096] These values ​​are double the traditional values. Note that while these values ​​are proposed for research, the actual values ​​that may be specified may be significantly greater to maximize cost savings.

[0097] There have been some discussions in 3GPP to support both legacy Rel-17 UEs and new eRedCap UEs, and two solutions have been proposed.

[0098] One solution is for the gNB to always use relaxed parameters K1 / K2 until the UE capabilities are known (e.g., the gNB can obtain the UE capabilities in Message 5 (Msg5) of the random access procedure). In other words, during initial access, until the gNB knows the UE capabilities, it must default to using longer processing times when scheduling PDSCH / PUSCH (i.e., using larger parameters K1 / K2). However, this solution introduces additional latency issues for non-eRedCap UEs (i.e., legacy Rel-17 UEs). For example, an additional access delay of 3-6 ms can occur during initial access for non-eRedCap UEs, which can be significant for delay-sensitive applications.

[0099] Another solution is for the gNB to handle this situation through implementation. For example, the gNB can define separate random access resources for RedCap UEs or use Message 1 (Msg1) to identify all RedCap UEs, and then only RedCap UEs will have a longer access time. The disadvantage of this solution is that it requires additional overhead (random access resource overhead).

[0100] Therefore, up to now, there is no effective way to provide support for legacy Rel-17 UEs and new eRedCap UEs with relaxed processing time without increasing the initial access delay for the legacy Rel-17 UEs.

[0101] According to an embodiment of the present disclosure, a scheme for processing time relaxation is provided. With this scheme, a terminal device determines that the processing time is insufficient to prepare an uplink transmission to a network device. In addition, the terminal device notifies the network device of the insufficient processing time.

[0102] This solution allows for processing time relaxation in eRedCap terminal devices without affecting system access latency for non-eRedCap terminal devices. In this way, it is possible to avoid system overhead, enable additional cost savings, and improve transmission efficiency. This solution can work without first identifying RedCap UEs in Meg1.

[0103] Figure 2 FIG2 illustrates a signaling flow 200 between a terminal device 110 and a network device 120 according to some example embodiments of the present disclosure. For the purpose of discussion, reference will be made to FIG2 . Figure 1A Let's describe the signaling flow 200.

[0104] like Figure 2As shown in FIG, terminal device 110 determines (205) that a processing time (also referred to as a first processing time) is insufficient to prepare an uplink transmission to network device 120. As an example, terminal device 110 may be a RedCap UE with relaxed processing capabilities. For example, the processing time may be associated with scheduling. As an example, the processing time may be a conventional processing time, i.e., a shorter processing time, than a relaxed processing time defined for an eRedCap UE, i.e., a longer processing time associated with the relaxed processing capabilities.

[0105] As an example, the uplink transmission may include the transmission of HARQ feedback for PDSCH from the network device 120 (e.g., HARQ feedback for Msg4 transmission), and in this case, the processing time may be used by the terminal device 110 to prepare for the HARQ feedback. As another example, the uplink transmission may include the transmission of PUSCH (e.g., Msg3 / 5 transmission), and in this case, the processing time may be used by the terminal device 110 to prepare for the transmission on the PUSCH.

[0106] For example, the processing time may be used during a random access procedure for the terminal device 110. Alternatively or additionally, the processing time may be used when the terminal device 110 is in radio resource control (RRC) inactive mode or RRC idle mode. In these cases, the network device 120 may use the conventional processing time during initial access (Msg3 / 4 / 5), or for transmissions with a terminal device 110 in idle / inactive mode (e.g., an eRedCap UE) when the network device 120 does not know the processing capabilities of the terminal device 110.

[0107] Then, if Figure 2 As shown in FIG, terminal device 110 notifies (210) network device 120 of insufficient processing time. Therefore, network device 120 determines (215) based on communicating with terminal device 110 that insufficient processing time is available for terminal device 110 to prepare an uplink transmission to network device 120.

[0108] In some example embodiments, terminal device 110 may send an indication of insufficient processing time to network device 120, such that network device 120 may be notified of the insufficient processing time. Then, upon receiving the indication from terminal device 110, network device 120 may determine that the processing time is insufficient for terminal device 110 to prepare for uplink transmission. For example, terminal device 110 may send an indication to network device 120 that the processing time configured in the DCI is too short.

[0109] In an example embodiment where the uplink transmission includes the transmission of HARQ feedback (i.e., ACK / NACK feedback), the terminal device 110 may indicate to the network device 120 via the PUCCH that it cannot meet the processing time requested by the network device 120 (e.g., using a PDSCH-to-HARQ_feedback timing indicator). For example, the indication may be sent on the PUCCH on which the HARQ feedback is scheduled or configured. In this case, the terminal device 110 may use the allocated PUCCH to send a message indicating that the processing time is insufficient. Alternatively or additionally, the indication may be sent on a PUCCH that is semi-persistently configured for the terminal device 110 to send the indication. In this case, the terminal device 110 may adopt a semi-statically configured PUCCH configuration to indicate that additional processing time is required.

[0110] In an example embodiment in which the uplink transmission includes the transmission of a PUSCH, the terminal device 110 may indicate to the network device 120 via the PUSCH or PUCCH that it cannot meet the processing time requested by the network device 120 (e.g., the time slot offset parameter for the PUSCH). As an example, the indication may be sent on a media access control (MAC) message mapped to the PUSCH. In this case, the indication may be sent in a short MAC message to indicate that the PUSCH preparation time is insufficient. As another example, the indication may be sent on a PUCCH in an existing format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured. In this case, the PUCCH may use an existing format with a different configuration. As another example, the indication may be sent on a PUCCH in a new format with a transmission resource defined for the indication using transmission resources on which the PUSCH is scheduled or configured. In this way, the indication may be sent on a special PUCCH in the Msg3 resource block location to indicate the additional processing time required by the terminal device 110 in order to allow the network device 120 to allocate UL resources for the PUSCH transmission. For example, the special PUCCH may be energy feedback in the last few symbols of the Msg3 indicating insufficient processing time.

[0111] In some example embodiments, terminal device 110 may omit sending an uplink transmission on a transmission resource on which the uplink transmission is scheduled or configured (also referred to as a first transmission resource). On the network side, network device 120 may determine that insufficient processing time exists based on not receiving the uplink transmission on the first transmission resource.

[0112] Then, if Figure 2As shown in FIG, the terminal device sends (220) an uplink transmission to the network device 120 based on another processing time (also referred to as a second processing time) that is sufficient for the terminal device 110 to prepare the uplink transmission. Accordingly, the network device 120 receives (225) an uplink transmission from the terminal device 110 based on the second processing time. The second processing time may be a relaxed processing time defined for the eRedCap UE and associated with a relaxed processing capability.

[0113] In some example embodiments, after determining that the first processing time is insufficient, terminal device 110 may determine a second transmission resource available for uplink transmission, for example based on the second processing time. Terminal device 110 may also send an uplink transmission on the second transmission resource to network device 120. Thus, after determining that the first processing time is insufficient, network device 120 may determine the second transmission resource and then receive the uplink transmission from terminal device 110 on the second transmission resource.

[0114] As an example, the second transmission resources may be reserved or preconfigured for uplink transmission. In this case, additional resources for uplink transmission may be reserved or preconfigured (e.g., implicitly determined based on the current resources used for uplink transmission) for the purpose that the terminal device 110 can send an uplink transmission after preparing the uplink transmission.

[0115] As another example, network device 120 may utilize retransmissions for PDSCH to send a new PDCCH grant to meet the second processing time for terminal device 110. Network device 120 may reschedule the second transmission resource for uplink transmission using parameters for sending uplink transmissions based on the second processing time (e.g., longer parameters compared to conventional parameters). Network device 120 may then send the parameters to terminal device 110. For example, if network device 120 determines that the first processing time is insufficient, it may send the parameters to terminal device 110.

[0116] On the terminal side, based on the received parameters, the terminal device 110 can then determine the second transmission resource. In an example embodiment in which the uplink transmission includes the transmission of HARQ feedback, the parameters may include a first parameter for determining the transmission timing of the HARQ feedback for the PDSCH. For example, the first parameter may be the parameter K1 described above. In this case, the network device 120 may use the longer parameter K1 for Msg4 to perform rescheduling. In an example embodiment in which the uplink transmission includes the transmission of the PUSCH, the parameters may include a second parameter for determining the transmission timing of sending the PUSCH. For example, the second parameter may be the parameter K2 described above. In this case, the network device 120 may use the longer parameter K2 for the PUSCH to perform rescheduling.

[0117] In the case of a DL transmission indicating that HARQ feedback is sent on the PUCCH on which it is scheduled or configured, the reserved or preconfigured second transmission resource may be used to send the HARQ feedback. Alternatively or additionally, the network device 120 may reschedule the second transmission resource for uplink transmission using a longer parameter K1.

[0118] In the case where the terminal device 110 adopts a semi-statically configured PUCCH configuration for sending an indicated DL transmission, when the terminal device 110 adopts this configuration to send a message (e.g., NACK feedback) on the PUCCH resource, the network device 120 can reschedule the downlink transmission for PDSCH (e.g., Msg4) or monitor the PUCCH at a timing aligned with the second processing time (i.e., the relaxed processing time).

[0119] In the case of DL transmission, the terminal device 110 may provide NACK feedback to the network device 120. The network device 120 may not reschedule the downlink transmission for the PDSCH (e.g., Msg4), but the terminal device 110 and the network device 120 may determine new transmission resources (e.g., new timing and position) for uplink transmission for the PDSCH based on the relaxed processing capabilities (e.g., the relaxed transmission timing of the eRedCap UE).

[0120] In the case where the network device 120 sends a DL transmission indicating a new PDCCH grant for retransmission of the PDSCH, the network device 120 may send an indication of the retransmission of the PDSCH to the terminal device 110, and then retransmit the PDSCH to the terminal device 110. In this case, the terminal device 110 may first determine whether the processing of the initial transmission of the PDSCH (e.g., the initial Msg4 transmission) is successful. If it is determined that the processing of the initial transmission is successful, the terminal device 110 may ignore the retransmission of the PDSCH. In other words, if the terminal device 110 is able to successfully decode the original transmission, it may discard or ignore the processing of the retransmission of the PDSCH. The terminal device 110 may then determine the HARQ feedback based on the result of the processing of the initial transmission. Otherwise, if it is determined that the processing of the initial transmission is unsuccessful, the terminal device 110 may perform HARQ merging of the initial transmission and retransmission of the PDSCH, and then determine the HARQ feedback based on the result of the HARQ merging. For example, the network device 120 may request the terminal device 110 to process the retransmission (implicitly or explicitly) via DCI and allow additional processing time for this. As an example, the explicit indication via DCI may be sent when the value of the parameter K1 is large enough to process the original transmission and the retransmission of the PDSCH, taking into account the timing of the PDCCH grant for the PDSCH.

[0121] In an example embodiment in which the terminal device 110 does not transmit anything on the first transmission resource, the network device 120 may detect this and assume that the terminal device 110 does not have sufficient processing time. The network device 120 may then, as an example, reschedule an uplink transmission for a longer preparation time using, for example, longer parameters K1 / K2. As another example, after omitting to send an uplink transmission on a transmission resource, the terminal device 110 may postpone the uplink transmission to the next available transmission resource. The network device 120 may receive the uplink transmission on the next available transmission resource. For the DL transmission case, the terminal device 110 may delay HARQ feedback until the next PUCCH, and in this case, the network device 120 may then need to check 2 HARQ feedback areas.

[0122] In this way, processing time relaxation is achieved in eRedCap terminal devices without affecting the system access latency for non-eRedCap terminal devices. Thus, system overhead can be avoided, additional cost savings can be achieved, and transmission efficiency can be improved. Furthermore, the proposed solution can work without first identifying the terminal device 110 as a RedCap UE in Msg1.

[0123] Figure 3A first example communication process 300 between a UE 301 and a gNB 303 according to some example embodiments of the present disclosure is illustrated. Specifically, Figure 3 An example signaling diagram for downlink processing time indication is shown. It should be understood that process flow 300 can be considered as follows Figure 2 . Thus, UE 301 may be an example of terminal device 110, and gNB 303 may be an example of network device 120.

[0124] like Figure 3 As shown in FIG, at 304, gNB 303 sends a synchronization signal block (SSB) with a master information block (MIB) to UE 301. At 306, gNB 303 sends a system information block (SIB) to UE 301. At 308, UE 301 sends Msg1 to gNB 303 on a physical random access channel (PRACH). At 310, UE 301 sends Msg3 to gNB 303 on a PUSCH.

[0125] At 312, gNB 303 sends a PDCCH with parameter K1, e.g., legacy parameter K1 (i.e., shorter parameter K1), to UE 301. At 314, gNB 303 sends Msg4 on the PDSCH to UE 301. At 316, UE 301 determines that it cannot meet the allocated K1 processing time determined based on parameter K1. At 318, UE 301 sends a PUCCH to gNB 303 indicating that the allocated K1 processing time is insufficient, using the K1 timing determined based on parameter K1.

[0126] At 320, based on the received PUCCH report indicating insufficient processing time, gNB 303 determines a new K1 timing, i.e., a new parameter K1, e.g., a longer parameter K1. At 322, gNB 303 sends a PDCCH with the longer parameter K1 to UE 301 indicating retransmission of Msg4. Then, at 324, gNB 303 retransmits the PDSCH with Msg4 to UE 301. At 326, UE 301 sends a PUCCH with HARQ feedback (i.e., ACK or NACK feedback) to gNB 303 based on the relaxed transmission timing determined based on the longer parameter K1.

[0127] Reference above Figure 2 The operations and features described are equally applicable to, and have similar effects in, process 300. For the sake of simplicity, details will be omitted.

[0128] Figure 4A second example communication process 300 between a UE 401 and a gNB 403 according to some example embodiments of the present disclosure is illustrated. Specifically, Figure 4 Another example signaling diagram for downlink processing time indication is shown. It should be understood that process flow 400 can be considered as follows Figure 2 . Thus, UE 401 may be an example of terminal device 110, and gNB 403 may be an example of network device 120.

[0129] like Figure 4 As shown in FIG, at 404, gNB 403 sends SSB with MIB to UE 401. At 406, gNB 403 sends SIB1 to UE 401. At 408, UE 401 sends Msg1 on PRACH to gNB 403. At 410, UE 401 sends Msg3 on PUSCH to gNB 403.

[0130] At 412, gNB 403 sends a PDCCH with parameter K1, e.g., legacy parameter K1 (i.e., shorter parameter K1), to UE 401. At 414, gNB 403 sends Msg4 on the PDSCH to UE 401. At 416, UE 401 determines that it cannot meet the allocated K1 processing time determined based on parameter K1.

[0131] At 418, UE 401 transmits a PUCCH to gNB 403, indicating that the allocated K1 processing time is insufficient, using the K1 timing determined based on parameter K1. At 420, UE 401 determines new PUCCH resources for transmitting HARQ feedback (i.e., ACK or NACK feedback). For example, the new PUCCH resources may be reserved or preconfigured for HARQ feedback. At 422, UE 401 transmits a PUCCH with HARQ feedback (i.e., ACK or NACK feedback) to gNB 403 using the new resources.

[0132] Figure 5 A third example communication process 500 between a UE 501 and a gNB 503 according to some example embodiments of the present disclosure is illustrated. Specifically, Figure 5 5. It should be understood that the process flow 500 may be considered as follows: Figure 2 . Thus, UE 501 may be an example of terminal device 110, and gNB 503 may be an example of network device 120.

[0133] like Figure 5As shown in FIG, at 504, gNB 503 sends SSB with MIB to UE 501. At 506, gNB 503 sends SIB1 to UE 501. At 508, UE 501 sends Msg1 to gNB 503 on PRACH. At 510, UE 501 sends Msg3 to gNB 503 on PUSCH.

[0134] At 512, gNB 503 sends a PDCCH with parameter K1 (e.g., legacy parameter K1 (i.e., shorter parameter K1)) to UE 501. At 514, gNB 503 sends Msg4 on the PDSCH to UE 501. At 516, UE 501 determines that it cannot meet the allocated K1 processing time determined based on parameter K1. At 518, UE 501 sends a PUCCH to gNB 503 indicating that the allocated K1 processing time is insufficient, using the K1 timing determined based on parameter K1.

[0135] At 520, UE 501 completes PDSCH processing. At 522, based on the PUCCH report indicating insufficient processing time, gNB 503 determines a new K1 timing, i.e., a new K1 parameter, e.g., a longer K1. At 524, gNB 503 sends a PDCCH with a longer K1 parameter and indicating a retransmission of Msg4 to UE 501. Then, gNB 503 retransmits the PDSCH with Msg4 to UE 501. At 526, UE 501 determines whether PDSCH processing was successful. If UE 501 correctly received the first PDSCH, it may ignore the retransmission. In this case, UE 501 may determine HARQ feedback based on the results of the first PDSCH transmission (i.e., the initial PDSCH transmission). Otherwise, if UE 501 incorrectly received the first PDSCH, it may perform HARQ combining of the first PDSCH transmission and the PDSCH retransmission and determine HARQ feedback based on the results of the HARQ combining. At 528, UE 501 sends a PUCCH with HARQ feedback (i.e., ACK or NACK feedback) to gNB 503 based on the relaxed transmission timing, which is determined based on the longer parameter K1.

[0136] Reference above Figure 2 The operations and features described are also applicable to, and have similar effects in, process 500. For the sake of simplicity, details will be omitted.

[0137] Figure 6 A fourth example communication process 600 between a UE 601 and a gNB 603 according to some example embodiments of the present disclosure is illustrated. Specifically, Figure 6An example signaling diagram for uplink processing time indication using PUSCH is shown. It should be understood that process flow 600 can be considered as follows Figure 2 . Thus, UE 601 may be an example of terminal device 110, and gNB 603 may be an example of network device 120.

[0138] like Figure 6 As shown in FIG, at 604, gNB 603 sends SSB with MIB to UE 601. At 606, gNB 603 sends SIB1 to UE 601. At 608, UE 601 sends Msg1 to gNB 603 on PRACH.

[0139] At 610, gNB 603 transmits a PDCCH with parameter K2, e.g., legacy parameter K2 (i.e., shorter parameter K2). At 612, gNB 603 transmits a PDSCH with Msg2 including a Random Access Response (RAR) uplink grant to UE 601. At 614, UE 601 determines that it cannot meet the allocated Msg3 preparation time determined based on parameter K2. At 616, UE 601 transmits a PUSCH to gNB 603 indicating that the allocated Msg3 preparation time is insufficient, using the K2 timing determined based on parameter K2.

[0140] Then, based on the received PUSCH indicating insufficient processing time, gNB 603 determines the relaxed parameter K2, i.e., the relaxed timing. At 618, gNB 603 sends a PDCCH with the relaxed parameter K2 to UE 601, indicating the retransmission of Msg3. Then, at 620, UE 601 retransmits the PUSCH with Msg3 to gNB 603 based on the relaxed timing determined based on the relaxed parameter K2.

[0141] Reference above Figure 2 The operations and features described are equally applicable to, and have similar effects in, process 600. For the sake of simplicity, details will be omitted.

[0142] Figure 7 A fifth example communication process 700 between a UE 701 and a gNB 703 according to some example embodiments of the present disclosure is illustrated. Specifically, Figure 7 An example signaling diagram for uplink processing time indication using PUCCH is shown. It should be understood that process flow 700 can be considered as follows Figure 2 . Thus, UE 701 may be an example of terminal device 110, and gNB 703 may be an example of network device 120.

[0143] like Figure 7 As shown in FIG, at 704, gNB 703 sends SSB with MIB to UE 701. At 706, gNB 703 sends SIB1 to UE 701. At 708, UE 701 sends Msg1 to gNB 703 on PRACH.

[0144] At 710, gNB 703 transmits a PDCCH with parameter K2, e.g., legacy parameter K2 (i.e., shorter parameter K2). At 712, gNB 703 transmits a PDSCH with Msg2 including an RAR uplink grant to UE 701. At 714, UE 701 determines that it cannot meet the allocated Msg3 preparation time determined based on parameter K2. At 716, UE 701 transmits a PUCCH (e.g., using format F0 or F1) to gNB 703 indicating that the allocated Msg3 preparation time is insufficient.

[0145] Then, based on the received PUCCH indicating insufficient processing time, gNB 703 determines the relaxed parameter K2, i.e., the relaxed timing. At 718, gNB 703 sends a PDCCH with the relaxed parameter K2 to UE 701, indicating the retransmission of Msg3. Then, at 720, UE 701 retransmits the PUSCH with Msg3 to gNB 703 based on the relaxed timing determined based on the relaxed parameter K2.

[0146] Reference above Figure 2 The operations and features described are also applicable to, and have similar effects in, process 700. For the sake of simplicity, details will be omitted.

[0147] Figure 8 FIGURE 800 illustrates a flow chart of a method implemented at a terminal device according to some embodiments of the present disclosure. For discussion purposes, reference will be made to Figure 1A The method 800 is described from the perspective of the terminal device 110 .

[0148] At block 810, terminal device 110 determines that processing time is insufficient to prepare an uplink transmission to network device 120. At block 820, terminal device 110 notifies network device 120 of the insufficient processing time.

[0149] In some example embodiments, to notify network device 120 , terminal device 110 may send an indication of insufficient processing time to network device 120 .

[0150] In some example embodiments, the uplink transmission may include transmission of HARQ feedback for a physical downlink shared channel (PDSCH). In some example embodiments, the indication may be sent on: a physical uplink control channel (PUCCH) on which the HARQ feedback is scheduled or configured; a semi-persistently configured PUCCH for terminal device 110 to transmit the indication; or any combination of the above.

[0151] In some example embodiments, the uplink transmission may include a transmission of a physical uplink shared channel (PUSCH). In some example embodiments, the indication may be sent in: a medium access control (MAC) message mapped to the PUSCH; a PUCCH in an existing format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured; a PUCCH in a new format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured; or any combination of the above.

[0152] In some example embodiments, to inform network device 120, terminal device 110 may omit sending uplink transmissions on the transmission resources on which the uplink transmissions are scheduled or configured.

[0153] In some example embodiments, the uplink transmission may be scheduled or configured on a first transmission resource, and in this case, terminal device 110 may further, after determining that the processing time is insufficient, determine a second transmission resource available for the uplink transmission, and then send the uplink transmission on the second transmission resource to network device 120. In some example embodiments, the second transmission resource may be reserved or preconfigured for the uplink transmission.

[0154] In an example embodiment where the processing time is a first processing time, terminal device 110 may further receive a parameter for sending an uplink transmission from network device 120 based on a second processing time sufficient to prepare for the uplink transmission, and then determine a second transmission resource based on the parameter. In some example embodiments, the parameter may include a first parameter for determining transmission timing of hybrid automatic repeat request (HARQ) feedback for a PDSCH, or a second parameter for determining transmission timing of a PUSCH.

[0155] In an example embodiment where the parameter includes the first parameter, terminal device 110 may further receive an indication of a retransmission of the PDSCH from network device 120. Terminal device 110 may ignore the retransmission of the PDSCH based on successful processing of the initial transmission of the PDSCH, and then determine HARQ feedback based on the result of processing the initial transmission. In some example embodiments, terminal device 110 may further perform HARQ combining of the initial transmission and the retransmission of the PDSCH based on unsuccessful processing of the initial transmission of the PDSCH, and then determine HARQ feedback based on the result of the HARQ combining.

[0156] In some example embodiments, the terminal device 110 may also defer uplink transmission to the next available transmission resource.

[0157] In some example embodiments, the processing time may be used during a random access procedure for the terminal device 110 , or may be used if the terminal device 110 is in a Radio Resource Control, RRC, inactive mode or an RRC idle mode.

[0158] Figure 9 A flowchart 900 of a method implemented at a network device according to some embodiments of the present disclosure is illustrated. For discussion purposes, reference will be made to Figure 1A Method 900 is described from the perspective of network device 120 .

[0159] At block 910, network device 120 determines, based on communicating with terminal device 110, that a first processing time is insufficient for terminal device 110 to prepare for an uplink transmission to network device 120. At block 920, network device 120 receives an uplink transmission from terminal device 110 based on a second processing time sufficient for terminal device 110 to prepare for the uplink transmission.

[0160] In some example embodiments, to determine that the first processing time is insufficient, network device 120 may receive an indication from terminal device 110 that the first processing time is insufficient.

[0161] In some example embodiments, the uplink transmission may include transmission of HARQ feedback for a physical downlink shared channel (PDSCH). In some example embodiments, the indication may be received on: a physical uplink control channel (PUCCH) on which the HARQ feedback is scheduled or configured; a semi-persistently configured PUCCH for terminal device 110 to transmit the indication; or any combination of the above.

[0162] In some example embodiments, the uplink transmission may include a transmission of a physical uplink shared channel (PUSCH). In some example embodiments, the indication may be received in: a medium access control (MAC) message mapped to the PUSCH; a PUCCH in an existing format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured; a PUCCH in a new format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured; or any combination of the above.

[0163] In some example embodiments, to determine that the first processing time is insufficient, network device 120 may determine that the first processing time is insufficient based on not receiving the uplink transmission on the transmission resource on which the uplink transmission is scheduled or configured.

[0164] In an example embodiment in which an uplink transmission is scheduled on a first transmission resource or configured to receive the uplink transmission, network device 120 may, after determining that the first processing time is insufficient, determine a second transmission resource based on a second processing time, and then receive the uplink transmission on the second transmission resource from terminal device 110. In some example embodiments, the second transmission resource may be reserved or preconfigured for uplink transmission.

[0165] In some example embodiments, network device 120 may further send parameters for sending the uplink transmission to terminal device 110 based on the second processing time before receiving the uplink transmission from terminal device 110. In some example embodiments, the parameters may include a first parameter for determining a transmission timing of hybrid automatic repeat request HARQ feedback for a physical downlink shared channel (PDSCH), or a second parameter for determining a transmission timing of sending a physical uplink shared channel (PUSCH).

[0166] In some example embodiments, to send the parameter, network device 120 may, based on determining that the first processing time is insufficient, send the parameter to terminal device 110. In an example embodiment where the parameter includes the first parameter, network device 120 may also send an indication of retransmission of the PDSCH to terminal device 110, and then resend the PDSCH to terminal device 110.

[0167] In some example embodiments, to receive an uplink transmission, network device 120 may receive the uplink transmission on the next available transmission resource.

[0168] In some example embodiments, the first processing time may be used during a random access procedure for the terminal device 110 or may be used if the terminal device 110 is in a radio resource control (RRC) inactive mode or an RRC idle mode.

[0169] In some example embodiments, an apparatus capable of executing method 800 (e.g., terminal device 110) may include a component for executing the corresponding steps of method 800. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit system or a software module.

[0170] In some example embodiments, the apparatus comprises: means for determining that processing time is insufficient to prepare an uplink transmission to the network device; and means for notifying the network device of the insufficient processing time.

[0171] In some example embodiments, the means for notifying the network device comprises means for sending an indication of insufficient processing time to the network device.

[0172] In some example embodiments, the uplink transmission includes transmission of HARQ feedback for a Physical Downlink Shared Channel (PDSCH). In some example embodiments, the indication is sent on at least one of: a Physical Uplink Control Channel (PUCCH) on which the HARQ feedback is scheduled or configured, or a semi-persistently configured PUCCH for the terminal device to transmit the indication.

[0173] In some example embodiments, the uplink transmission comprises a transmission of a physical uplink shared channel (PUSCH). In some example embodiments, the indication is sent in at least one of: a medium access control (MAC) message mapped to the PUSCH; a PUCCH in an existing format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured; or a PUCCH in a new format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured.

[0174] In some example embodiments, the means for notifying the network device includes means for omitting sending the uplink transmission on the transmission resources on which the uplink transmission is scheduled or configured.

[0175] In some example embodiments, an uplink transmission is scheduled or configured on a first transmission resource, and the apparatus further comprises: means for determining, after determining insufficient processing time, a second transmission resource available for the uplink transmission; and means for sending the uplink transmission to the network device on the second transmission resource. In some example embodiments, the second transmission resource is reserved or preconfigured for uplink transmission.

[0176] In some example embodiments, the processing time is a first processing time and the apparatus further comprises: means for receiving, from the network device, a parameter for sending an uplink transmission based on a second processing time sufficient to prepare for the uplink transmission; and means for determining a second transmission resource based on the parameter. In some example embodiments, the parameter comprises one of: a first parameter for determining transmission timing of hybrid automatic repeat request (HARQ) feedback for a PDSCH; or a second parameter for determining transmission timing of a PUSCH.

[0177] In some example embodiments, the parameter includes a first parameter, and the apparatus further includes: means for receiving an indication of a retransmission of a PDSCH from a network device; means for ignoring the retransmission of the PDSCH based on successful processing of an initial transmission of the PDSCH; and means for determining HARQ feedback based on a result of processing the initial transmission. In some example embodiments, the apparatus further includes: means for performing HARQ combining of the initial transmission and the retransmission of the PDSCH based on unsuccessful processing of the initial transmission of the PDSCH; and means for determining HARQ feedback based on a result of the HARQ combining.

[0178] In some example embodiments, the apparatus further comprises means for deferring the uplink transmission to a next available transmission resource.

[0179] In some example embodiments, the processing time is used during a random access procedure for the terminal device, or is used if the terminal device is in a Radio Resource Control, RRC, inactive mode or an RRC idle mode.

[0180] In some example embodiments, the apparatus further comprises means for performing other steps of some embodiments of method 800. In some embodiments, the means comprises at least one processor and at least one memory comprising computer program code. The at least one memory and the computer program code are configured to, together with the at least one processor, enable execution of the apparatus.

[0181] In some example embodiments, an apparatus capable of executing method 900 (e.g., a network device) may include a component for executing the corresponding steps of method 900. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit system or a software module.

[0182] In some example embodiments, the apparatus includes: means for determining, based on communicating with the terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; and means for receiving an uplink transmission from the terminal device based on a second processing time sufficient for the terminal device to prepare for the uplink transmission.

[0183] In some example embodiments, means for determining that the first processing time is insufficient includes means for receiving an indication from the terminal device that the first processing time is insufficient.

[0184] In some example embodiments, the uplink transmission includes transmission of HARQ feedback for a physical downlink shared channel (PDSCH). In some example embodiments, the indication is received on at least one of: a physical uplink control channel (PUCCH) on which the HARQ feedback is scheduled or configured, or a semi-persistently configured PUCCH for the terminal device to transmit the indication.

[0185] In some example embodiments, the uplink transmission comprises a transmission of a physical uplink shared channel (PUSCH). In some example embodiments, the indication is received in at least one of: a medium access control (MAC) message mapped to the PUSCH; a PUCCH in an existing format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured; or a PUCCH in a new format with a configuration defined for the indication using transmission resources on which the PUSCH is scheduled or configured.

[0186] In some example embodiments, means for determining that the first processing time is insufficient includes means for determining that the first processing time is insufficient based on not receiving the uplink transmission on the transmission resource on which the uplink transmission is scheduled or configured.

[0187] In some example embodiments, an uplink transmission is scheduled or configured on a first transmission resource, and the means for receiving the uplink transmission includes: means for determining a second transmission resource based on a second processing time after determining that the first processing time is insufficient; and means for receiving the uplink transmission from the terminal device on the second transmission resource. In some example embodiments, the second transmission resource is reserved or preconfigured for uplink transmission.

[0188] In some example embodiments, the apparatus further comprises: means for transmitting, to the terminal device, a parameter for transmitting an uplink transmission based on the second processing time, before receiving the uplink transmission from the terminal device. In some example embodiments, the parameter comprises one of: a first parameter for determining transmission timing of hybrid automatic repeat request (HARQ) feedback for a physical downlink shared channel (PDSCH); or a second parameter for determining transmission timing of a physical uplink shared channel (PUSCH). In some example embodiments, the means for transmitting the parameter comprises means for transmitting the parameter to the terminal device based on determining that the first processing time is insufficient.

[0189] In some example embodiments, the parameter comprises a first parameter, and the apparatus further comprises: means for sending an indication of a retransmission of the PDSCH to the terminal device; and means for resending the PDSCH to the terminal device. In some example embodiments, the means for receiving an uplink transmission comprises: means for receiving the uplink transmission on the next available transmission resource.

[0190] In some example embodiments, the first processing time is used during a random access procedure for the terminal device, or is used if the terminal device is in a Radio Resource Control, RRC, inactive mode or an RRC idle mode.

[0191] In some example embodiments, the apparatus further comprises means for performing other steps in some embodiments of method 900. In some embodiments, the means comprises at least one processor and at least one memory comprising computer program code. The at least one memory and the computer program code are configured to, together with the at least one processor, enable execution of the apparatus.

[0192] Figure 10 1 shows a simplified block diagram of a device 1000 suitable for implementing some example embodiments of the present disclosure. The device 1000 may be provided to implement a communication device, such as Figure 1A The terminal device 110 or the network device 120 is shown. As shown in the figure, the device 1000 includes one or more processors 1010, one or more memories 1020 coupled to the processor 1010, and one or more communication modules 1040 coupled to the processor 1010.

[0193] The communication module 1040 is used for two-way communication. The communication module 1040 has at least one antenna to facilitate communication. The communication interface can represent any interface required to communicate with other network elements.

[0194] Processor 1010 may be of any type suitable for the local technology network and, as non-limiting examples, may include one or more of the following: a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 1000 may have multiple processors, such as application specific integrated circuit chips that are time-slave to a clock synchronized with a main processor.

[0195] The memory 1020 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1024, electrically programmable read-only memory (EPROM), flash memory, hard disks, compact disks (CDs), digital video disks (DVDs), and other magnetic and / or optical storage devices. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1022 and other volatile memories that do not persist during a power outage.

[0196] Computer program 1030 includes computer executable instructions executed by associated processor 1010. Program 1030 may be stored in read-only ROM 1024. Processor 1010 may perform any suitable actions and processes by loading program 1030 into RAM 1022.

[0197] The embodiments of the present disclosure can be implemented with the aid of the program 1030, so that the device 1000 can execute the following steps: Figures 2 to 7 Any process of the present disclosure discussed. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0198] In some example embodiments, program 1030 may be tangibly embodied in a computer-readable medium that may be included in device 1000 (such as in memory 1020) or in other storage devices accessible by device 1000. Device 1000 may load program 1030 from the computer-readable medium into RAM 1022 for execution. Computer-readable media may include any type of tangible, non-volatile storage, such as ROM, EPROM, flash memory, hard disk, CD, DVD, and the like.

[0199] Figure 11 FIG10 illustrates a block diagram of an example of a computer readable medium 1100 according to some example embodiments of the present disclosure. The computer readable medium 1100 has a program 1030 stored thereon. Note that although the computer readable medium 1100 is Figure 11 Although depicted in the form of a CD or DVD, computer readable medium 1100 may be in any other form suitable for carrying or storing program 1030.

[0200] In general, various embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are illustrated and described as block diagrams, flow charts, or using some other graphical representations, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0201] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer executable instructions, such as instructions included in a program module, that are executed in a device on a target real or virtual processor to perform the operations described above with reference to Figures 8 and 9 . Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The functionality of program modules can be combined or divided between program modules as needed in various embodiments. Machine-executable instructions for program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in both local and remote storage media.

[0202] The program code for executing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code, when executed by the processor or controller, causes the function / operation specified in the flow chart and / or block diagram to be realized. The program code can be executed entirely on the machine, partially on the machine, as an independent software package, partially on the machine and partially on a remote machine, or completely on a remote machine or server.

[0203] In the context of the present disclosure, computer program codes or related data may be carried by any suitable carrier, such as a signal or a computer-readable medium, so that a device, apparatus, or processor can perform the various processes and operations described above.

[0204] Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing.More specific examples of computer-readable storage media include electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or Flash memories), optical fibers, portable compact disc read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.As used herein, the term "non-transient" refers to a limitation on the medium itself (i.e., tangible, rather than signal), rather than a limitation on data storage persistence (e.g., RAM versus ROM).

[0205] In addition, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or requiring that all operations shown be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these details should not be interpreted as limiting the scope of this disclosure, but should be interpreted as descriptions of features peculiar to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0206] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Instead, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A terminal device, comprising: at least one processor; as well as At least one memory storing instructions, which, when executed by the at least one processor, cause the terminal device to at least: determining that the processing time is insufficient to prepare an uplink transmission to the network device; and The network device is notified that the processing time is insufficient.

2. The terminal device according to claim 1, wherein the terminal device is caused to notify the network device by: An indication of insufficient processing time is sent to the network device. 3 . The terminal device according to claim 2 , wherein the uplink transmission comprises transmission of HARQ feedback for a physical downlink shared channel (PDSCH).

4. The terminal device according to claim 3, wherein the indication is sent on at least one of the following: The HARQ feedback is scheduled or configured on the Physical Uplink Control Channel PUCCH, or A semi-persistently configured PUCCH for the terminal device to send the indication.

5. The terminal device according to claim 2, wherein the uplink transmission comprises transmission of a physical uplink shared channel (PUSCH).

6. The terminal device according to claim 5, wherein the indication is sent in at least one of the following: a medium access control MAC message mapped to the PUSCH; a PUCCH in an existing format with a configuration defined for the indication using the transmission resources on which the PUSCH is scheduled or configured; or A PUCCH in a new format defined for the indication is used with transmission resources on which the PUSCH is scheduled or configured.

7. The terminal device according to claim 1, wherein the terminal device is caused to notify the network device by: Transmitting the uplink transmission on the transmission resources on which the uplink transmission is scheduled or configured is omitted.

8. The terminal device according to any one of claims 1 to 7, wherein the uplink transmission is scheduled or configured on a first transmission resource, and the terminal device is further caused to: After determining that the processing time is insufficient, determining a second transmission resource that can be used for the uplink transmission; and The uplink transmission is sent to the network device on the second transmission resource.

9. The terminal device according to claim 8, wherein the second transmission resource is reserved or preconfigured for the uplink transmission.

10. The terminal device according to claim 8, wherein the processing time is a first processing time, and the terminal device is further caused to: receiving, from the network device, parameters for sending the uplink transmission based on a second processing time sufficient to prepare the uplink transmission; and Based on the parameter, the second transmission resource is determined.

11. The terminal device according to claim 10, wherein the parameter comprises one of the following items: A first parameter for determining a transmission timing of a hybrid automatic repeat request (HARQ) feedback for a PDSCH; or The second parameter is used to determine the transmission timing of sending the PUSCH.

12. The terminal device according to claim 11, wherein the parameters include the first parameter, and the terminal device is further caused to: receiving an indication of retransmission of the PDSCH from the network device; Based on successful processing of the initial transmission of the PDSCH, ignoring the retransmission of the PDSCH; and The HARQ feedback is determined based on a result of the processing of the initial transmission.

13. The terminal device according to claim 12, wherein the terminal device is further configured to: performing HARQ combining of the initial transmission and the retransmission of the PDSCH based on unsuccessful handling of the initial transmission of the PDSCH; and The HARQ feedback is determined based on a result of the HARQ combining.

14. The terminal device according to claim 7, wherein the terminal device is further configured to: The uplink transmission is deferred until the next available transmission resource.

15. The terminal device according to any one of claims 1 to 14, wherein the processing time is used during a random access procedure for the terminal device, or is used when the terminal device is in a radio resource control (RRC) inactive mode or an RRC idle mode.

16. A network device comprising: at least one processor; as well as At least one memory storing instructions, which, when executed by the at least one processor, cause the network device to at least: determining, based on communicating with a terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; as well as The uplink transmission is received from the terminal device based on a second processing time sufficient for the terminal device to prepare for the uplink transmission.

17. The network device of claim 16, wherein the network device is caused to determine that the first processing time is insufficient by: An indication that the first processing time is insufficient is received from the terminal device.

18. The network device of claim 17, wherein the uplink transmission comprises: Transmission of HARQ feedback for the Physical Downlink Shared Channel (PDSCH).

19. The network device of claim 18, wherein the indication is received on at least one of: The HARQ feedback is scheduled or configured on the Physical Uplink Control Channel PUCCH, or A semi-persistently configured PUCCH for the terminal device to send the indication.

20. The network device of claim 17, wherein the uplink transmission comprises a transmission of a Physical Uplink Shared Channel (PUSCH).

21. The network device of claim 20, wherein the indication is received in at least one of the following: A medium access control MAC message mapped to the PUSCH, a PUCCH in an existing format with a configuration defined for the indication using the transmission resources on which the PUSCH is scheduled or configured; or A PUCCH in a new format defined for the indication is used with transmission resources on which the PUSCH is scheduled or configured.

22. The network device of claim 16, wherein the network device is caused to determine that the first processing time is insufficient by: Insufficient first processing time is determined based on not receiving the uplink transmission on transmission resources on which the uplink transmission is scheduled or configured.

23. The network device of any one of claims 16 to 22, wherein the uplink transmission is scheduled or configured on a first transmission resource, and the network device is caused to receive the uplink transmission by: After determining that the first processing time is insufficient, determining a second transmission resource based on the second processing time; and The uplink transmission is received from the terminal device on the second transmission resource.

24. The network device of claim 23, wherein the second transmission resource is reserved or preconfigured for the uplink transmission.

25. The network device of claim 23, wherein the network device is further caused to: Prior to receiving the uplink transmission from the terminal device, parameters for sending the uplink transmission are sent to the terminal device based on the second processing time.

26. The network device of claim 25, wherein the parameter comprises one of the following: A first parameter for determining a transmission timing of a hybrid automatic repeat request HARQ feedback for a physical downlink shared channel PDSCH; or The second parameter is used to determine the transmission timing of sending the Physical Uplink Shared Channel PUSCH.

27. The network device according to claim 25 or 26, wherein the network device is caused to send the parameter by: Based on determining that the first processing time is insufficient, the parameter is sent to the terminal device.

28. The network device of claim 26, wherein the parameters include the first parameter, and the network device is further caused to: Sending an indication of retransmission of the PDSCH to the terminal device; and Resend the PDSCH to the terminal device.

29. The network device of claim 22, wherein the network device is caused to receive the uplink transmission by: The uplink transmission is received on the next available transmission resource.

30. The network device according to any one of claims 16 to 29, wherein the first processing time is used during a random access procedure for the terminal device, or is used when the terminal device is in a radio resource control (RRC) inactive mode or an RRC idle mode.

31. A method comprising: determining at the terminal device that processing time is insufficient to prepare an uplink transmission to the network device; as well as The network device is notified that the processing time is insufficient.

32. A method comprising: determining, at the network device based on communicating with the terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; as well as The uplink transmission is received from the terminal device based on a second processing time sufficient for the terminal device to prepare for the uplink transmission.

33. An apparatus comprising: means for determining, at the terminal device, that processing time is insufficient to prepare an uplink transmission to the network device; as well as A component for notifying the network device of insufficient processing time.

34. An apparatus comprising: means for determining, at the network device, based on communicating with the terminal device, that a first processing time is insufficient for the terminal device to prepare an uplink transmission to the network device; as well as means for receiving the uplink transmission from the terminal device based on a second processing time sufficient for the terminal device to prepare the uplink transmission.

35. A non-transitory computer-readable medium comprising program instructions for causing an apparatus to at least perform the method according to claim 31 or 32.

Images