Method and apparatus for physical uplink shared channel transmission with and without random access channel

Abstract

Various solutions for (autonomous) retransmission of random access channel (RACH) and RACH-less (or contention-based) physical uplink shared channel (PUSCH) are described. An apparatus can receive a configuration from a network node. The configuration includes a plurality of parameters related to one or more contention-based PUSCH or RACH transmissions (e.g., initial transmissions and / or (autonomous) retransmissions). The apparatus can select one or more contention-based PUSCH resource occasions or one or more RACH resource occasions in accordance with the configuration. The apparatus can then perform the one or more contention-based PUSCH or RACH transmissions to the network node on the one or more contention-based PUSCH resource occasions or the one or more RACH resource occasions.

Description

[0001] Cross-references

[0002] This disclosure is part of a non-provisional application that claims priority to PCT application No. PCT / CN2024 / 122702, filed on September 30, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically, to transmissions (e.g., initial transmissions and / or (autonomous) retransmissions) on random access channels (RACH) and contention-free (or contention-based) physical uplink shared channels (PUSCH). Background Technology

[0004] Unless otherwise stated, the methods described in this section are not prior art to the following claims and are not considered prior art by virtue of their inclusion in this section.

[0005] Wireless communication technologies have experienced exponential growth over the years. Long Term Evolution (LTE) systems offer peak data rates, low latency, increased system capacity, and lower operating costs due to a simplified network architecture. LTE systems, also known as 4G... th The 4G system can also be seamlessly integrated into legacy wireless networks such as GSM, CDMA, and Universal Mobile Telecommunications System (UMTS). In LTE systems, the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) includes multiple evolved Node Bs (eNodeBs or eNBs) that communicate with multiple mobile stations, referred to as User Equipment (UEs). 3 rd 3GPP (3rd Generation Partnership Project) networks typically include a hybrid of 2G / 3G / 4G systems. The Next Generation Mobile Network (NGMN) Board has decided to focus future NGMN activities on defining 5G... th End-to-end requirements for next-generation (5G) new radio (NR) systems and 6G systems.

[0006] In 5G NR, the initial access procedure is a crucial stage for the UE to establish a connection with the network and initiate communication. To reduce uplink (UL) and downlink (DL) signaling overhead during the initial access procedure in advanced scenarios (e.g., future terrestrial network (TN) and / or non-terrestrial network (NTN) scenarios), new designs for RACH-free and RACH-based procedures are needed to achieve more efficient signaling. Therefore, how to design new RACH-free and RACH-based procedures to improve the efficiency of the initial access procedure has become an important issue for newly developed wireless communication systems. Consequently, it is necessary to provide appropriate solutions to address this problem. Summary of the Invention

[0007] The following summary is for illustrative purposes only and is not intended to be limiting. That is, the following summary aims to introduce the concepts, key points, benefits, and advantages of the novel and non-obvious techniques described herein. Some embodiments will be further described in the detailed description below. Therefore, the following summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to define the scope of the claimed subject matter.

[0008] One objective of this disclosure is to provide schemes, concepts, designs, systems, methods, and apparatuses related to RACH and RACH-free (or contention-based) PUSCH transmission. It is believed that by implementing one or more of the schemes proposed herein, the aforementioned problems can be avoided or mitigated.

[0009] In one aspect, a method may involve receiving configuration from a network node by a device, wherein the configuration includes a plurality of parameters relating to transmissions of one or more contention-based PUSCH or RACH. The method may also involve the device selecting one or more contention-based PUSCH resource times or one or more RACH resource times according to the configuration. The method may further involve the device performing the transmission of the one or more contention-based PUSCH or RACH to the network node on the one or more contention-based PUSCH resource times or the one or more RACH resource times.

[0010] In one aspect, a method may involve a network node sending a configuration to a device, wherein the configuration includes a plurality of parameters relating to one or more contention-based PUSCH or RACH transmissions. The method may also involve the network node receiving, from the device, a transmission of one or more contention-based PUSCH or RACH at one or more contention-based PUSCH resource times or one or more RACH resource times.

[0011] In one aspect, an apparatus may include a transceiver that wirelessly communicates with a network node during operation. The apparatus may also include a processor communicatively connected to the transceiver. During operation, operations that the processor can perform include receiving a configuration from the network node via the transceiver, wherein the configuration includes a plurality of parameters related to one or more contention-based PUSCH or RACH transmissions. Operations that the processor can also perform include selecting one or more contention-based PUSCH resource timings or one or more RACH resource timings according to the configuration. Operations that the processor can further perform include performing the one or more contention-based PUSCH or RACH transmissions to the network node via the transceiver on the one or more contention-based PUSCH resource timings or the one or more RACH resource timings.

[0012] It is worth noting that although the descriptions provided herein may be made in the context of certain wireless access technologies, networks, and network topologies, such as Long-Term Evolution (LTE), Advanced LTE, LTE Plus, 5th Generation (5G), New Radio (NR), Internet of Things (IoT), Narrow Band Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), Beyond 5G (B5G), and 6th Generation (6G), the proposed concepts, schemes, and any variations / derivatives thereof can be implemented, used, and implemented by other types of wireless access technologies, networks, and network topologies. Therefore, the scope of this disclosure is not limited to the examples described herein. Attached Figure Description

[0013] The accompanying drawings are included in this specification to further understand this disclosure and form part of this disclosure. The drawings illustrate embodiments of this disclosure and, together with the specification, serve to explain the principles of this disclosure. It will be understood that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to actual implementations for clarity of the concepts of this disclosure.

[0014] Figure 1 The illustration depicts an example scenario of a communication environment in which various solutions and schemes of this disclosure can be implemented.

[0015] Figure 2 For illustrative purposes, an example scenario of (autonomous) RACH or contention-based PUSCH retransmission in a general process according to an embodiment of this disclosure is described.

[0016] Figure 3 For illustrative purposes, an example scenario of retransmission of (autonomous) RACH or competition-based PUSCH according to an embodiment of this disclosure is described.

[0017] Figure 4 For illustrative purposes, an example scenario of retransmission of another (autonomous) RACH and competition-based PUSCH according to an embodiment of this disclosure is described.

[0018] Figure 5 The diagram illustrates an example communication system according to an embodiment of this disclosure.

[0019] Figure 6 The flowchart illustrates an example process according to an embodiment of this disclosure.

[0020] Figure 7 The flowchart illustrates another example flow according to an embodiment of this disclosure. Detailed Implementation

[0021] This specification discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matter, which can be implemented in various forms. This disclosure can be embodied in many different forms and should not be construed as being limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided to make the description of this disclosure thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art. In the following description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

[0022] Overview

[0023] According to embodiments of this disclosure, various techniques, methods, schemes, and / or solutions relate to RACH and RACH-free (or competition-based) PUSCH transmission. According to this disclosure, multiple possible solutions can be implemented individually or in combination. That is, although these possible solutions are described individually below, two or more solutions can be implemented in some combination.

[0024] In this disclosure, NTN refers to a network that provides communication services to a UE by utilizing radio frequency (RF) and information processing resources carried by high-, medium-, and low-Earth orbit satellites or other high-altitude communication platforms. Depending on the payload capabilities of the satellite, there are two typical scenarios: transparent payload and regenerative payload. In transparent payload mode, the satellite does not process the signals and waveforms in the communication service, but only acts as an RF amplifier to forward data. In regenerative payload mode, in addition to RF amplification, the satellite also possesses processing capabilities such as modulation / demodulation, encoding / decoding, switching, and routing.

[0025] In 5G NR, the initial access procedure (RACH) is a crucial stage for the UE to establish a connection with the network and initiate communication. In traditional designs, the UE needs to perform a RACH procedure for the target cell, such as uplink synchronization, to establish a connection. The RACH procedure for initial access typically involves the UE sending a RACH preamble, receiving resource and timing information from the network, sending a connection request, and then receiving an acknowledgment to complete the connection with a unique identifier. To reduce the latency introduced by the RACH procedure, the concept of a RACH-free procedure was introduced, allowing the UE to skip certain steps of the RACH procedure (e.g., sending message 1 (Msg1) and receiving message 2 (Msg2) in the 4-step random access procedure) and communicate directly with the target cell, for example, when the UE and the target cell are in good timing synchronization. However, in some advanced scenarios (e.g., (future) TN and / or NTN scenarios), the communication system may need to support a large number and variety of UEs. Therefore, to unlock additional uplink capacity potential, new designs for both RACH-free and RACH procedures are needed to achieve more efficient signaling, thereby striking a balance between throughput and burst packet loss rate.

[0026] In view of the above, this disclosure proposes several schemes related to RACH and RACH-free (or competition-based) PUSCH transmissions (e.g., initial transmission and / or (autonomous) retransmissions), driven by but not limited to NTN scenarios. Specifically, the scheme proposed in this disclosure aims to introduce innovative methods in the following aspects: (i) contention-based PUSCH (re)transmission configuration; (ii) Hybrid Automatic Repeat Request (HARQ) operation for contention-based PUSCH (re)transmission; (iii) uplink grant determination procedure for contention-based PUSCH (e.g., without RACH message 3 (Msg3)); (iv) contention-based resolution procedure for contention-based PUSCH (e.g., without RACH Msg3); (v) completion of the contention-based PUSCH (e.g., without RACH PUSCH or without RACH Msg3) procedure; (vi) power control for contention-based PUSCH (e.g., without RACH PUSCH or without RACH Msg3) (re)transmission; (vii) RACH (re)transmission configuration; and (viii) RACH (re)transmission configuration procedure. Therefore, by applying the scheme of this disclosure, the performance and efficiency of random access procedures can be improved, and initial access latency can be reduced.

[0027] It should be noted that in this disclosure, the following terms are interchangeable: "RACH-free" and "competition-based"; the following terms are also interchangeable: "PUSCH" and "Msg3". For example, "RACH-free PUSCH" can be replaced with "competition-based PUSCH" and vice versa; "RACH-free Msg3" can be replaced with "competition-based Msg3" and vice versa; "RACH-free PUSCH" can be replaced with "RACH-free Msg3" and vice versa; "competition-based PUSCH" can be replaced with "competition-based Msg3", etc.

[0028] Figure 1 Example scenario 100 of a communication environment is illustrated, in which various solutions and schemes of this disclosure can be implemented. Scenario 100 involves UE 110 wirelessly communicating with network 120 (e.g., a wireless network including NTN and TN) via terrestrial network node 122 (e.g., base station (BS), such as eNB, next-generation Node-B (gNB), transceiver point (TRP), relay, or gateway) and / or non-terrestrial network node 124 (e.g., satellite). For example, in transparent payload mode, terrestrial network node 122 (e.g., BS) and non-terrestrial network node 124 (e.g., satellite acting as relay) can form an NTN serving cell to wirelessly communicate with UE 110. In regenerative payload mode, non-terrestrial network node 124 (e.g., satellite) may have all or part of the gNB functionality and can form an NTN serving cell to wirelessly communicate with UE 110 with or without the participation of terrestrial network node 122 (e.g., BS). Alternatively, terrestrial network node 122 can form a TN serving cell to wirelessly communicate with UE 110. In such a communication environment, UE110, network 120, and terrestrial network node 122 and / or non-terrestrial network node 124 can implement the various schemes related to RACH and RACH-free (or contention-based) PUSCH transmissions described in this disclosure, as follows. It is worth noting that although the various proposed schemes may be described separately or individually below, in practice, some or all of the proposed schemes may be used or implemented in combination. Of course, each proposed scheme can also be used or implemented individually or separately.

[0029] Figure 2This document illustrates a general procedure example scenario 200 for RACH or contention-based PUSCH (autonomous) retransmission in embodiments of this disclosure. In step 201, the UE receives RACH and contention-based PUSCH (retransmission) configurations from the network node via a wide beam, provided through System Information Block (SIB) type-X (SIB-X) (e.g., SIB-1, SIB-19 / 20 for NTN, and SIB-31 / 32 for IoT NTN). In step 202, the UE performs RACH or contention-based PUSCH (CB-PUSCH) transmissions on a narrow beam at randomly selected PRACH / PUSCH timings (e.g., selected from PRACH / PUSCH resource timings configured for RACH or no RACH Msg3 via SIB or Radio Resource Control (RRC) signaling). In step 203, the UE determines whether RACH / CB-PUSCH (autonomous) retransmission is configured / enabled. If (autonomous) retransmission of RACH / CB-PUSCH is configured / enabled, the process proceeds to step 204; if not, the process proceeds to step 205. In step 204, the UE can increase the cumulative number of RACH / CB-PUSCH retransmissions and check whether N is less than the maximum number of RACH / CB-PUSCH retransmissions N_thr configured by the network. If N is less than N_thr, the process returns to step 202 and retransmits RACH / CB-PUSCH. Otherwise, if N is not less than N_thr, the process proceeds to step 205. In step 205, the UE monitors the response message corresponding to the (retransmission) of RACH / CB-PUSCH on a narrow beam, within a no-RACH window or a random access response (RAR) window.

[0030] Figure 3 An example scenario 300 of RACH or contention-based PUSCH (autonomous) retransmission in embodiments of this disclosure is illustrated. Figure 3 As shown, when RACH / CB-PUSCH (autonomous) retransmission is configured / enabled, the UE can retransmit the initial RACH / CB-PUSCH transmission multiple times before there is no RACH or RAR window (e.g., ...). Figure 3 (N is used to represent the retransmission), where the time interval between two consecutive (re)transmissions can be determined by the retransmission offset. It is worth noting that in traditional random access procedure designs, RACH / Msg3 retransmissions only occur after a RACH or RAR window is closed, which inevitably prolongs the initial access delay. Compared to traditional designs, the RACH / CB-PUSCH (autonomous) retransmission proposed in this disclosure can effectively reduce this delay by allowing the UE to perform multiple retransmissions at an earlier time, without being subject to the time constraints associated with a RACH or RAR window.

[0031] Additionally, in some embodiments, a dedicated offset for RACH-less PUSCH or RACH can be set as the round-trip time (RTT) between the UE and a network node (e.g., gNB). That is, by setting the offset to RTT. UE-gNB Retransmission can be performed after there is no RACH or RAR window.

[0032] Figure 4 An example scenario 400 of RACH and competition-based PUSCH (autonomous) retransmission in embodiments of this disclosure is shown. Figure 4 Part A describes the (autonomous) retransmission scenario based on competition-based PUSCH (denoted as RACH-free PUSCH). Figure 4 Part B describes the (autonomous) retransmission scenario for RACH. In both scenarios, the retransmission offset between two consecutive (retransmissions) can be configured separately. For example, the retransmission offset between two consecutive (retransmissions) without RACH PUSCH can be determined based on two parameters: a retransmission timer for the RACH-free PUSCH and a dedicated offset for the RACH-free PUSCH. Similarly, the retransmission offset between two consecutive RACH (retransmissions) can be determined based on two parameters: a retransmission timer for RACH and a dedicated offset for RACH.

[0033] In some embodiments, if no RACH preamble has been sent to the network node previously, the contention-based PUSCH may include a no-RACH Msg3 during the random access procedure. Alternatively, during the data transmission procedure, if the UE is in connected mode (e.g., RRC_CONNECTED mode), the contention-based PUSCH may include a no-RACH PUSCH.

[0034] Under the first scheme of this disclosure, a contention-based PUSCH (retransmission) configuration is proposed as follows. The network can configure at least one of the following parameters to the user equipment (UE) for (autonomous) retransmission without RACH PUSCH / Msg3 via Radio Resource Control (RRC) signaling, System Information Block (SIB), Medium Access Control (MAC) Control Element (CE), or Downlink Control Information (DCI). The parameters of the contention-based PUSCH (retransmission) configuration may include: (i) an enable indication (e.g., referred to as autonomousTx_RACH-LESS PUSCH) indicating whether contention-based (autonomous) retransmission is enabled; (ii) an enable indication (e.g., referred to as autonomousTx_RACH-LESS PUSCH)... (iii) A retransmission timer value (e.g., called RACH-LESS_MSG3-RRC-RetransmissionTimer), representing the initial value of the retransmission timer for the retransmission offset between two consecutive (retransmissions) of a contention-based Msg3, expressed in multiples of the period; (iv) A retransmission timer value (e.g., called RACH-LESS_PUSCH-RRC-RetransmissionTimer), representing the initial value of the retransmission timer for the retransmission offset between two consecutive (retransmissions) of a contention-based PUSCH, expressed in multiples of the period; (v) A contention resolution timer value (e.g., called RACH-LESS_MSG4-contentionresolutionTimer), representing the contention resolution timer used to monitor the length of Msg4 corresponding to the contention-based Msg3 for contention resolution. (vi) The initial value of the contention resolution timer; (vii) The contention resolution timer value (e.g., referred to as RACH-LESS-contentionresolutionTimer), representing the initial value of the contention resolution timer used to monitor the length of the response message corresponding to the contention-based PUSCH in order to resolve the contention; (vii) The Hybrid Automatic Repeat Request (HARQ) ID offset (e.g., referred to as harq-ID-Offset), representing the offset of the HARQ process ID used for retransmission of contention-based PUSCH / Msg3; (viii) The offset (e.g., referred to as RACH-LESS_offset), representing the offset at which the retransmission timer (e.g., RACH-LESS_MSG3-RRC-RetransmissionTimer or RACH-LESS_PUSCH-RRC-RetransmissionTimer) begins;(ix) Maximum retransmission timer value (e.g., called RACH-LESS-RRC-RetransmissionMaxTimer), representing the length of a contention-based PUSCH / Msg3 (autonomous) retransmission, expressed as a multiple of the period; (x) Maximum number of retransmissions (e.g., called RACH-LESS-RRC-RetransmissionMax), representing the maximum number of contention-based PUSCH / Msg3 (autonomous) retransmissions; (xi) Fallback indication (e.g., called Fallback_to_4step), indicating whether a 4-step RACH procedure should be executed after a contention-based PUSCH failure; and (xii) Fallback time (e.g., called RACH-LESS_BACKOFF), representing the fallback duration when the 4-step RACH procedure starts after a contention-based PUSCH failure.

[0035] If the enable indication autonomousTx_RACH-LESS PUSCH or autonomousTx_RACH-LESS Msg3 is present, it indicates that contention-based (autonomous) retransmission of PUSCH / Msg3 is configured. This field can be 1 bit long, and when the value of this field is set to 1, it indicates that contention-based (autonomous) retransmission of PUSCH / Msg3 is enabled. This field indicates that autonomousTx_RACH-LESS Msg3 is also valid for any subsequent contention-based PUSCH transmissions prior to autonomousTx_RACH-LESS PUSCH configuration.

[0036] This field indicates that RACH-LESS_MSG3-RRC-RetransmissionTimer and RACH-LESS_PUSCH-RRC-RetransmissionTimer can be 3, 4, 5, or 6 bits long, respectively. The value of RACH-LESS MSG3-RRC-RetransmissionTimer or RACH-LESS_PUSCH-RRC-RetransmissionTimer is always less than or equal to the value of RACH-LESS_MSG4-contentionresolutionTimer or RACH-LESS-contentionresolutionTimer. This field can be configured along with harq-ID-Offset. Specifically, this field indicates the duration of the HARQ process for the initial transmission of contention-based PUSCH / Msg3 after a contention-based PUSCH / Msg3 (retransmission). This field also indicates that RACH-LESS_MSG3-RRC-RetransmissionTimer is valid for any subsequent contention-based PUSCH transmissions before RACH-LESS_PUSCH-RRC-RetransmissionTimer is configured.

[0037] The field indicates that RACH-LESS_MSG4-contentionresolutionTimer and RACH-LESS-contentionresolutionTimer can be 3, 4, 5, or 6 bits long, respectively. For example, value=sf8 corresponds to 8 subframes, value=sf16 corresponds to 16 subframes, and so on. The field also indicates that RACH-LESS_MSG4-contentionresolutionTimer is valid for any subsequent contention-based PUSCH transmissions prior to RACH-LESS-contentionresolutionTimer configuration.

[0038] The field indicating RACH-LESS_offset can be configured to 0 or RTT. UE-gNB .

[0039] The field indicates that RACH-LESS-RRC-RetransmissionMaxTimer can be 3, 4, 5, or 6 bits in length. RACH-LESS-RRC-RetransmissionMaxTimer can be started on the first symbol after all repetitions of a contention-based PUSCH / Msg3 initial transmission have ended. Specifically, this field indicates the duration of contention-based PUSCH / Msg3 retransmissions allowed by the HARQ process for retransmitting the initial transmission.

[0040] The field indicating RACH-LESS-RRC-RetransmissionMax can be 3, 4, 5, or 6 bits in length.

[0041] The field indicating Fallback_to_4step can be 1 bit long. When this field is configured to 1, it indicates that a 4-step RACH procedure is enabled after a contention-based PUSCH / Msg3 procedure fails.

[0042] The field indicating RACH-LESS_BACKOFF can be 3, 4, 5, or 6 bits long.

[0043] Under the second scheme of this disclosure, a contention-based PUSCH (retransmission) HARQ operation is proposed as follows. When contention-based Msg3 (autonomous) retransmission is enabled, if the UE does not receive a contention-based Msg4 before the configured timer (e.g., retransmission timer) expires, or if the UE does not receive the contention resolution ID of the contention-based Msg4 within the RACH-LESS_MSG4-contention resolution window, the UE can retransmit the initial contention-based Msg3 transmission. After the initial contention-based Msg3 transmission, subsequent retransmissions of contention-based Msg3 can be handled differently depending on the resource type used to initiate the contention-based Msg3 transmission procedure. For example, when using contention-based Msg3 resources, subsequent retransmissions of contention-based Msg3 can be performed on subsequent periodic resource opportunities of contention-based Msg3, where the contention-based Msg3 resource opportunity can be randomly selected by the UE. Alternatively, when using dedicated / UE-specific contention-based Msg3 resources (which can be triggered by physical downlink control channel (PDCCH) commands), the network can schedule subsequent retransmissions of contention-based Msg3 at the timing of contention-based Msg3 resource allocation via dynamic uplink (UL) granting, downlink (DL) allocation, or RRC signaling allocation.

[0044] When contention-based PUSCH (autonomous) retransmission is enabled in connected mode (e.g., RRC_CONNECTED mode), if the UE does not receive a contention resolution ID, dynamic UL authorization, or DL ​​allocation from the network before the configured timer (e.g., retransmission timer) expires, or if the UE does not receive a contention resolution ID, dynamic UL authorization, or DL ​​allocation from the network within the configured window, the UE can retransmit the initial contention-based PUSCH transmission. After the initial contention-based PUSCH transmission, subsequent retransmissions of contention-based PUSCH can be handled differently depending on the resource type used to initiate the contention-based PUSCH transmission procedure. For example, when using contention-based PUSCH resources, subsequent retransmissions of contention-based PUSCH can occur on subsequent periodic resource opportunities for contention-based PUSCH, where the contention-based PUSCH resource opportunity can be randomly selected by the UE. Alternatively, when using dedicated / UE-specific contention-based PUSCH resources, the network can schedule subsequent retransmissions of contention-based PUSCHs on the timing of contention-based PUSCH resource allocation via dynamic UL authorization, DL allocation, or RRC signaling.

[0045] More detailed HARQ operations regarding retransmission success and failure based on competitive (autonomous) PUSCH are further presented in Tables 1 and 2 below.

[0046]

[0047] Table 1

[0048] Table 2

[0049] Under the third scheme of this disclosure, a UL authorization determination process for contention-based PUSCH / Msg3 is proposed as follows. A MAC entity may possess UL authorization for transmission on the uplink shared channel (SCH). To execute the requested transmission, the MAC layer receives HARQ information from a lower layer (e.g., the physical layer, or L1 layer). The initial and (autonomous) retransmission UL authorization for contention-based PUSCH / Msg3 is determined by the following steps, as associated with the PUSCH resources for contention-based PUSCH / Msg3: (i) randomly selecting a PUSCH opportunity (e.g., in the msg3-CB-PUSCH information element (IE)) from among the PUSCH resource opportunities configured for contention-based PUSCH / Msg3 via SIB / RRC; (ii) determining the UL authorization and associated HARQ information for contention-based PUSCH / Msg3 in the selected PUSCH opportunity; and (iii) transmitting the UL authorization and associated HARQ information to the HARQ entity.

[0050] Under the fourth scheme of this disclosure, a competition-based PUSCH / Msg3 competition resolution process is proposed, as shown in Table 3 below.

[0051]

[0052] Table 3

[0053] Under the fifth scheme of this disclosure, a contention-based PUSCH / Msg3 procedure is proposed to be completed as follows. After the random access of the contention-based PUSCH / Msg3 procedure is completed, the MAC entity may: (i) discard any contention-free random access explicitly indicated for contention-based PUSCH / Msg3 transmission, except for random access to contention-based PUSCH / Msg3 resources used for beam fault recovery requests; and (ii) refresh the HARQ buffer used for transmitting MAC Protocol Data Units (PDUs) in the contention-based PUSCH / Msg3 buffer. After the successful completion of the contention-based PUSCH / Msg3 procedure random access initiated for a dual-active protocol stack (DAPS) handover, the target MAC entity may indicate to the upper layer (e.g., the RRC layer) that the contention-based PUSCH / Msg3 procedure random access has been successfully completed.

[0054] Under the sixth scheme of this disclosure, a power control method based on the contention-based PUSCH / Msg3 procedure is proposed as follows: The UE can determine the transmit power for contention-based PUSCH / Msg3 at transmission timing i, on the active uplink bandwidth portion (BWP) b of carrier f in cell c, based on the downlink (DL) reference signal (RS) of cell c. _(RACH-LESS PUSCH, , , ) ( ),as follows: [dBm] During transmission Inside, targeting the community carrier Maximum output power configured by the UE. It is a high-rise building as a community carrier The active uplink bandwidth portion (UL BWP) Provided contention-based PUSCH target received power RACH-LESS PUSCH_RECEIVED_ TARGET_POWER . It is for carrier waves UL BWP activities Based on the community The path loss calculated by the UE on the contention-based PUSCH transmission associated downlink reference signal (DL RS) on the active downlink bandwidth portion (DL BWP) is expressed in dB by the formula: referenceSignalPower – Higher Layer Filtered Reference Signal Received Power (RSRP), in dBm. If the active DL BWP is the initial DL BWP and is used for synchronization signal (SS) or physical broadcast channel (PBCH) blocks and CORESET multiplexing modes 2 or 3 (as described in Clause 13 of 3GPP TS 38.213), or for non-serving cells, the UE determines the path loss based on the SS / PBCH block associated with the contention-based PUSCH transmission. If the UE's contention-based PUSCH / Msg3 transmission is not in response to a PDCCH command detected by the UE, or is a contention-based random access that triggers a contention-based PUSCH / Msg3 procedure in response to a PDCCH command detected by the UE, or is related to a link recovery procedure, then referenceSignalPower is provided by ss-PBCH-BlockPower.

[0055] Under the seventh scheme of this disclosure, the RACH (retransmission) configuration is proposed as follows. The network can configure at least one of the following parameters for RACH (autonomous) retransmission for the UE via Radio Resource Control (RRC) / System Information Block (SIB) / Media Access Control (MAC) Control Element (CE) / Downlink Control Information (DCI). The parameters of the RACH (retransmission) configuration may include: (i) an enable indicator (e.g., autonomousTx_RACH) indicating whether RACH (autonomous) retransmission is enabled; (ii) a retransmission timer value (e.g., RACH-RRC-RetransmissionTimer) representing the initial value of the retransmission timer for the retransmission offset between two consecutive RACH (retransmissions), expressed as a multiple of the period; (iii) the offset at which the retransmission timer starts (e.g., RACH_offset) (e.g., RACH-RRC-RetransmissionTimer); (iv) a maximum retransmission timer value (e.g., RACH-RRC-RetransmissionMaxTimer) representing the length of the RACH (autonomous) retransmission, expressed as a multiple of the period; and (v) a maximum number of retransmissions (e.g., RACH-RRC-RetransmissionMax) representing the maximum number of RACH (autonomous) retransmissions.

[0056] If the enable indicator autonomousTx_RACH exists, it means that RACH (autonomous) retransmission is configured. This field can be 1 bit long, and when the value of this field is set to 1, it means that RACH (autonomous) retransmission is enabled.

[0057] The field indicates that RACH-RRC-RetransmissionTimer can be 3, 4, 5, or 6 bits long. The value of RACH-RRC-RetransmissionTimer is always less than or equal to the value of RACH-contentionresolutionTimer.

[0058] The field indicates that RACH-RRC-RetransmissionMaxTimer can be 3, 4, 5, or 6 bits long. RACH-RRC-RetransmissionMaxTimer can be started on the first symbol after all initial RACH transmission repetitions have ended.

[0059] The field indicating RACH-RRC-RetransmissionMax can be 3, 4, 5, or 6 bits in length.

[0060] Under the eighth scheme of this disclosure, the RACH (re)transmission configuration process is proposed as shown in Table 4 below.

[0061]

[0062] Table 4

[0063] Example Implementation

[0064] Figure 5 An example communication system 500 according to an embodiment of this disclosure is shown, including an example communication device 510 and an example network device 520. The communication device 510 and the network device 520 are capable of performing various functions to implement the schemes, techniques, processes, and methods described herein related to RACH and RACH-free (or contention-based) PUSCH transmission, including the above-described scenarios / schemes and processes 600 and 700 described below.

[0065] The communication device 510 may be part of an electronic device, which may be a UE (User Equipment), such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, the communication device 510 may be implemented in a smartphone, smartwatch, personal digital assistant, electronic control unit (ECU) in a vehicle, digital camera, or computing device such as a tablet, laptop, or notebook computer. The communication device 510 may also be part of a machine-type device, which may be an Internet of Things (IoT), Narrowband Internet of Things (NB-IoT), or Industrial Internet of Things (IIoT) UE, such as a non-movable or fixed device, a home device, a roadside unit (RSU), a wired communication device, or a computing device. For example, the communication device 510 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. Alternatively, the communication device 510 may be implemented in the form of one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more Reduced Instruction Set Computing (RISC) processors, or one or more Complex Instruction Set Computing (CISC) processors. The communication device 510 may include... Figure 5 The components shown include at least some components, such as processor 512. Communication device 510 may also include one or more other components unrelated to this disclosure (e.g., internal power supply, display device, and / or user interface device); therefore, for the sake of brevity, Figure 5 These components of the communication device 510 are not shown and are not described below.

[0066] Network device 520 may be part of an electronic device, which may be a network node, such as a satellite, base station (BS), cell, router, or gateway for a 4G / 5G / B5G / 6G, NR, Internet of Things (IoT), Narrowband Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), or non-terrestrial network (NTN) network. For example, network device 520 may be implemented in an eNB / gNB / TRP in a satellite or 4G / 5G, NR, IoT, NB-IoT, IIoT, or NTN network. Alternatively, network device 520 may be implemented as one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, or one or more Reduced Instruction Set Computer (RISC) or Complex Instruction Set Computer (CISC) processors. Network device 520 may include... Figure 5 The network device 520 may include at least some of the components shown, such as processor 522. It may also include one or more other components unrelated to this disclosure (e.g., internal power supply, display device, and / or user interface device), therefore, for the sake of brevity, these components of the network device 520 are not listed in the [disclosure details]. Figure 5 This is shown in the text and not described in the following text.

[0067] In one aspect, each of processors 512 and 522 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, although the singular term "processor" is used herein to refer to processors 512 and 522, each of processors 512 and 522 may include multiple processors in some implementations and a single processor in others, depending on the different implementations of this disclosure. In another aspect, each of processors 512 and 522 may be implemented in hardware (and optionally firmware) and include electronic components, such as, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more transformers, configured and arranged to achieve a particular purpose according to the requirements of this disclosure. In other words, in at least some implementations, each of processors 512 and 522 is a dedicated machine specifically designed, arranged, and configured to perform specific tasks in devices (e.g., communication device 510) and network nodes (e.g., network device 520), conforming to various implementations of this disclosure.

[0068] In some implementations, communication device 510 may further include a transceiver 516 connected to processor 512, capable of wirelessly transmitting and receiving data. In some implementations, transceiver 516 may be capable of wireless communication with wireless networks of different types of user equipment (UEs) and / or different radio access technologies (RATs). In some implementations, transceiver 516 may be equipped with multiple antenna ports (not shown), such as four antenna ports. That is, transceiver 516 may be equipped with multiple transmit antennas and multiple receive antennas for beamforming and multiple-input multiple-output (MIMO) wireless communication. In some implementations, network device 520 may further include a transceiver 526 connected to processor 522. Transceiver 526 may include a transceiver capable of wirelessly transmitting and receiving data. In some implementations, transceiver 526 may be capable of wireless communication with different types of UEs of different RATs. In some implementations, transceiver 526 may be equipped with multiple antenna ports (not shown), such as four antenna ports. In other words, transceiver 526 can be equipped with multiple transmit antennas and multiple receive antennas for beamforming and MIMO wireless communication.

[0069] In some implementations, the communication device 510 may further include a memory 514 connected to the processor 512, which can access and store data therein. In some implementations, the network device 520 may further include a memory 524 connected to the processor 522, which can access and store data therein. Each of the memories 514 and 524 may include a random access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitance RAM (Z-RAM). Alternatively, each of the memories 514 and 524 may include a read-only memory (ROM), such as a mask ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), and / or electrically erasable programmable ROM (EEPROM). Alternatively, each of the memories 514 and 524 may include a non-volatile random access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase-change memory.

[0070] Both communication device 510 and network device 520 can be communication entities capable of communicating using various schemes of this disclosure. For illustrative purposes and without limitation, the capabilities of communication device 510 as a UE and network device 520 as a network node are described below, in conjunction with procedures 600 and 700.

[0071] Example Process

[0072] Figure 6 An example flow 600 of this disclosure is illustrated. Flow 600 can be an example implementation of the aforementioned scenario / scheme, whether partial or complete, involving RACH and RACH-free (or contention-based) PUSCH transmissions. Flow 600 can represent one aspect of the functional implementation of communication device 510. Flow 600 can include one or more operations, actions, or functions, as shown in flow blocks 610 to 630. Although shown in discrete blocks, the individual blocks of flow 600 can be divided into more blocks, merged into fewer blocks, or omitted as needed for the desired implementation. Furthermore, the individual blocks of flow 600 can be arranged according to... Figure 6 The process can be executed in the order shown, or in a different order. Process 600 can be implemented by communication device 510 or any suitable UE or machine-type device. For illustrative purposes only and without limitation, process 600 is described below in the context of communication device 510 as a UE and network device 520 as a network node (e.g., satellite / gNB / TRP / relay). Process 600 may begin at block 610.

[0073] In block 610, process 600 may involve the processor 512 of communication device 510 receiving configuration from network device 520 via transceiver 516, wherein the configuration includes multiple parameters related to one or more contention-based PUSCH or RACH transmissions. Process 600 may continue from block 610 to block 620.

[0074] In block 620, process 600 may involve processor 512 selecting one or more contention-based PUSCH resource opportunities or one or more RACH resource opportunities based on this configuration. Process 600 may continue from block 620 to block 630.

[0075] In block 630, process 600 may involve processor 512, via transceiver 516, performing one or more contention-based PUSCH or RACH transmissions to network device 520 on one or more contention-based PUSCH resource opportunities or one or more RACH resource opportunities.

[0076] In some implementations, the transmission of one or more contention-based Physical Uplink Shared Channel (PUSCH) or Random Access Channel (RACH) may include at least one initial transmission and one or more contention-based PUSCH or RACH retransmissions, and may be performed by network device 520 before or after a time window for monitoring response messages corresponding to the contention-based PUSCH or RACH.

[0077] In some implementations, the plurality of parameters may include at least one of the following: (i) an enable indicator with a first value indicating that retransmission of the one or more contention-based PUSCHs or RACHs is enabled, or an enable indicator with a second value indicating that retransmission of the one or more contention-based PUSCHs or RACHs is not enabled; (ii) a first timer value representing the initial value of a retransmission timer for the length between two consecutive retransmissions in the retransmission of the one or more contention-based PUSCHs or RACHs, expressed as a multiple of the period; (iii) a second timer value representing the initial value of a contention resolution timer for monitoring the length of the response message corresponding to the contention-based PUSCH or RACH; (iv) a hybrid automatic repeat request (HARQ) process identifier (ID) offset for retransmission of the one or more contention-based PUSCHs; (v) an offset from which the retransmission timer starts; (vi) a third timer value representing the maximum retransmission timer value for the retransmission length of the one or more contention-based PUSCHs or RACHs, expressed as a multiple of the period; (vii) Maximum number of times, indicating the maximum number of times the one or more contention-based PUSCH or RACH retransmissions can be performed; (viii) rollback indication, indicating whether the 4-step RACH procedure should be executed after the contention-based PUSCH fails; and (ix) rollback time, indicating the rollback duration when the 4-step RACH procedure is started after the contention-based PUSCH fails.

[0078] In some implementations, this configuration can be received via a system information block (SIB), radio resource control (RRC) signaling, medium access control (MAC) control element (CE), or downlink control information (DCI).

[0079] In some implementations, the enable indicator can be configured to a first value indicating that retransmission of the one or more contention-based PUSCHs is enabled, and the retransmission of the one or more contention-based PUSCHs can be performed on one of the following events: (i) Event: No response message corresponding to the contention-based PUSCH is received before the expiration of a timer configured for the device, the timer being used to receive the response message; (ii) Event: The contention resolution identifier (ID) of the response message is not correctly received within the contention resolution window; (iii) Event: Before the expiration of a timer configured for the device, the response message corresponding to the contention resolution ID of the contention-based PUSCH, dynamic uplink (UL) grant, or downlink (DL) allocation is not received from the network node or is not correctly received from the network node, the timer being used to receive the response message; (iv) Event: In the configuration window or contention resolution window, the UE does not receive or correctly receives from the network node the response message corresponding to the contention-based PUSCH, dynamic UL authorization, or DL ​​allocation, and the window is used for the UE to receive the response message.

[0080] In some implementations, the enable indication may be configured to a first value indicating that the one or more RACH retransmissions are enabled. Furthermore, process 600 may also include processor 512 incrementing a counter (e.g., RACH-LESS_MSG3_TRANSMISSION_COUNTER) for the total number of contention-based PUSCH retransmissions before performing the one or more RACH retransmissions, and, when the counter value reaches its maximum, indicating a random access problem to an upper layer (e.g., the RRC layer), or determining that the random access procedure has not been successfully completed.

[0081] In some implementations, the transmission of the one or more contention-based PUSCHs can be performed via a HARQ process associated with an uplink (UL) grant, which is determined for at least one of the initial transmission and retransmissions of the one or more contention-based PUSCHs, and occurs in at least one of the following events: (i) Event: The UL grant is configured and the enable indication is set to a first value; (ii) Event: A failure indication for the contention-based PUSCH of the initial transmission is received; (iii) Event: The retransmission timer has not expired after the start of the contention-based PUSCH of the initial transmission; (iv) Event: The total number of retransmissions of the one or more contention-based PUSCHs has not reached the maximum number or has not reached any other value less than or equal to the maximum number; (v) Event: The total number of transmissions of the one or more contention-based PUSCHs (including the initial transmission and the one or more retransmissions) has not reached the maximum number or has not reached any other value less than or equal to the maximum number.

[0082] In some implementations, selecting one or more contention-based PUSCH resource times may include randomly selecting one or more PUSCH times from a plurality of PUSCH resource times configured for the contention-based PUSCH. Additionally, or optionally, process 600 may also include processor 512 determining one or more UL authorizations within the selected one or more PUSCH times for retransmission of the one or more contention-based PUSCH times.

[0083] In some implementations, process 600 may further include the processor 512 starting or restarting the contention resolution timer after the first symbol following all the initial transmissions and the retransmissions of the one or more contention-based PUSCHs, plus the round-trip time (RTT) between the communication device 510 and the network device 520, wherein the RTT is set to a non-zero value when the network device 520 is a non-terrestrial network node and a zero value when the network device 520 is a terrestrial network node. Furthermore, process 600 may also include processor 512 determining, in one of the following events, that the contention-based PUSCH has been successfully completed and the contention associated with the contention-based PUSCH has been successfully resolved: (i) First event: The contention-based PUSCH contains a MAC control element (CE) with a cell-radio network temporary identifier (C-RNTI), and a physical downlink control channel (PDCCH) transmission for the C-RNTI containing a new transmission UL license is received; (ii) Second event: The contention-based PUSCH contains a common control channel (CCCH) service data unit (SDU), and a PDCCH transmission for a contention-based RNTI (CB-RNTI) configured for communication device 510 is received, and the following conditions are met: (C1) The MAC protocol data unit (PDU) is successfully decoded; (C2) The contention resolution timer is triggered due to the MAC... The process stops upon successful PDU decoding; (C3) the MAC PDU contains a MAC CE with a UE contention resolution identifier; and (C4) the UE contention resolution identifier in the MAC CE matches the identifier transmitted by the CCCH SDU in the contention-based PUSCH. Alternatively, process 600 may further include processor 512 determining, in the second event, that contention resolution related to the contention-based PUSCH was unsuccessful if any of conditions C1 to C4 are not met.

[0084] In some implementations, process 600 may also involve processor 512 determining, in the event that a contention resolution timer expires, that contention resolution related to a contention-based PUSCH has failed, and incrementing a retransmission count counter (e.g., RACH-LESS_MSG3_TRANSMISSION_COUNTER) for the one or more contention-based PUSCHs when the contention resolution is determined to be unsuccessful. Furthermore, process 600 may also involve processor 512 determining, in the event that a counter value reaches its maximum count, that the contention-based PUSCH has failed to complete, and in the event that a backoff indication indicates that a four-step RACH procedure needs to be executed after the failure of the contention-based PUSCH, sending a RACH preamble to network device 520 via transceiver 516 after the backoff time.

[0085] In some implementations, process 600 may also involve processor 512 performing at least one of the following after determining that the contention-based PUSCH has been successfully completed: (i) discarding any contention-free random access that explicitly indicates a retransmission of the initial transmission and the one or more contention-based PUSCHs; (ii) flushing the HARQ buffers used for the retransmission of the initial transmission and the one or more contention-based PUSCHs; and (iii) indicating to the upper layer of the MAC entity of communication device 510 that the contention-based PUSCH has been successfully completed.

[0086] In some implementations, process 600 may also involve processor 512 determining the transmit power of the one or more contention-based PUSCH transmissions based on the target receive power of the contention-based PUSCH and the reference signal power of the downlink (DL) reference signal (RS) associated with the one or more contention-based PUSCH transmissions.

[0087] Figure 7 An example flow 700 according to an embodiment of this disclosure is illustrated. Flow 700 can serve as an example implementation of the above-described scenario / solution, whether partially or entirely, involving RACH and RACH-free (or contention-based) PUSCH transmissions. Flow 700 can represent one aspect of a characteristic implementation of network device 520. Flow 700 may include one or more operations, actions, or functions as shown by one or more modules 710 and 720 in the figures. Although illustrated as discrete modules, the modules of flow 700 may be divided into more modules, merged into fewer modules, or omitted depending on the desired implementation. Furthermore, the modules of flow 700 may be arranged as follows: Figure 7The process can be executed in the order shown, or in a different order. Process 700 can be implemented by network device 520 and any variant thereof. For illustrative purposes only and without limitation, process 700 is described below with communication device 510 as the UE and network device 520 as a network node (e.g., satellite / gNB / TRP / relay). Process 700 may begin with module 710.

[0088] In module 710, process 700 may involve the processor 522 of network device 520 sending a configuration to communication device 510 via transceiver 526, wherein the configuration includes multiple parameters related to one or more contention-based PUSCH or RACH transmissions. Process 700 may enter module 720 from module 710.

[0089] In module 720, process 700 may involve processor 522 receiving, via transceiver 526, transmissions of one or more contention-based PUSCH or RACH from communication device 510 at one or more contention-based PUSCH resource times or one or more RACH resource times.

[0090] In some implementations, the retransmission of the one or more contention-based PUSCHs or RACHs may include at least one initial transmission and the retransmission of the one or more contention-based PUSCHs or RACHs, and may be received before or after the time window in which the response message corresponding to the contention-based PUSCH or RACH is sent to the communication device 510.

[0091] In some implementations, the plurality of parameters may include at least one of the following: (i) an enable indicator having a first value indicating that retransmission of the one or more contention-based PUSCHs or RACHs is enabled, or an enable indicator having a second value indicating that retransmission of the one or more contention-based PUSCHs or RACHs is not enabled; (ii) a first timer value representing the initial value of a retransmission timer for the length between two consecutive retransmissions in the one or more contention-based PUSCHs or RACHs, expressed as a multiple of the period; (iii) a second timer value representing the initial value of a contention resolution timer for monitoring the length of the response message corresponding to the contention-based PUSCH or RACH; (iv) for The following are the following parameters: (v) the offset of the HARQ process identifier (ID) for retransmission of one or more contention-based PUSCHs; (vi) the third timer value, representing the maximum retransmission timer value for the retransmission length of one or more contention-based PUSCHs or the RACH, expressed as a multiple of the period; (vii) the maximum number of retransmissions, representing the maximum number of retransmissions of one or more contention-based PUSCHs or the RACH; (viii) the backoff indication, indicating whether a four-step RACH procedure should be executed after the failure of the contention-based PUSCH; and (ix) the backoff time, representing the backoff duration value when the four-step RACH procedure is started after the failure of the contention-based PUSCH.

[0092] In some implementations, this configuration can be sent via System Information Block (SIB), Radio Resource Control (RRC) signaling, Media Access Control (MAC) Control Element (CE), or Downlink Control Information (DCI).

[0093] Additional notes

[0094] The topics described in this specification sometimes show different components contained in or connected to other different components. It should be understood that such illustrated architectures are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” to achieve the desired function. Therefore, any two components combined herein to achieve a particular function can be considered “associated with each other” to achieve the desired function, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operationally connected” or “operationally coupled” to achieve the desired function, and any two components that can be suchly associated can also be considered “operationally coupled” to achieve the desired function. Specific examples of operational coupling include, but are not limited to, physically matable and / or physically interactive components and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.

[0095] Furthermore, regarding the use of almost all plural and / or singular terms in this document, those skilled in the art can appropriately convert plural to singular and / or singular to plural depending on the context and / or application. Various singular / plural arrangements are explicitly listed herein for clarity.

[0096] Furthermore, those skilled in the art will understand that the terms commonly used herein, particularly in appended claims, such as the body portion of appended claims, are generally intended as “open” terms; for example, “including” should be interpreted as “including but not limited to,” “having” should be interpreted as “having at least,” and “includes” should be interpreted as “including but not limited to,” etc. Those skilled in the art will also understand that if a specific number of claim elements is expressly expressed in the claim, then that intention is expressly expressed in the claim; if not, then this intention does not exist. For example, for ease of understanding, the following appended claims may contain the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed as limiting any particular claim containing that element to containing only one of that element, even if the same claim contains the introductory phrases "one or more" or "at least one" and indefinite articles such as "one (a)" or "one (an)". For example, "one (a)" and / or "one (an)" should be interpreted as "at least one" or "one or more"; the same applies to definite articles used to introduce claim elements. Furthermore, even if a specific number of claim elements is explicitly expressed, those skilled in the art will recognize that the expression should be interpreted as at least the stated number. For example, expressing only "two elements" without other modifiers indicates at least two elements, or two or more elements. Additionally, when using conventions such as "at least one A, B, and C, etc.", this structure is generally intended to be interpreted in a way that is understood by those skilled in the art. For example, "a system having at least one A, B, and C" includes, but is not limited to, systems with only A, only B, only C, A and B, A and C, B and C, and systems with A, B, and C, etc. When using conventions such as "at least one A, B, or C," this structure is generally intended to be interpreted in a manner understood by one of the art. For example, "a system having at least one A, B, or C" includes, but is not limited to, systems with only A, only B, only C, A and B, A and C, B and C, and systems with A, B, and C. Those skilled in the art will further understand that almost all extractive terms and / or phrases presenting two or more alternative terms in the specification, claims, or drawings should be understood to include one, any, or both terms. For example, "A or B" should be understood to include the possibility of "A" or "B" or "A and B."

[0097] As can be seen from the foregoing, various embodiments of this disclosure have been described herein for illustrative purposes, and various modifications can be made without departing from the scope and spirit of this disclosure. Therefore, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit are indicated by the following claims.

Claims

1. A method comprising: The device's processor receives a configuration from a network node, wherein the configuration includes multiple parameters related to one or more transmissions based on a contention-based Physical Uplink Shared Channel (PUSCH) or Random Access Channel (RACH); The processor selects one or more contention-based PUSCH resource opportunities or one or more RACH resource opportunities based on the configuration; and The processor performs the one or more contention-based PUSCH or RACH transmissions to the network node during one or more contention-based PUSCH resource opportunities or one or more RACH resource opportunities.

2. The method as described in claim 1, wherein, The one or more transmissions of the contention-based PUSCH or the RACH include at least one initial transmission and one or more retransmissions of the contention-based PUSCH or the RACH, and are performed before or after a time window for monitoring response messages corresponding to the contention-based PUSCH or the RACH, the response messages originating from the network node.

3. The method as described in claim 2, wherein, These parameters include at least one of the following: An enable indicator with a first value indicates that the one or more retransmissions of the contention-based PUSCH or the RACH are enabled, or an enable indicator with a second value indicates that the one or more retransmissions of the contention-based PUSCH or the RACH are not enabled. The first timer value represents the initial value of the retransmission timer for the length between two consecutive retransmissions in one or more retransmissions of the contention-based PUSCH or the RACH, expressed as a multiple of the period. The second timer value represents the initial value of the contention resolution timer used to monitor the length of the response message corresponding to the contention-based PUSCH or RACH. Hybrid Automatic Repeat Request (HARQ) process identifier (ID) offset used for the one or more retransmissions of the contention-based PUSCH; The offset at the start of the retransmission timer; The third timer value represents the maximum retransmission timer value for the one or more retransmission lengths used for the contention-based PUSCH or the RACH, expressed as a multiple of the period. Maximum number of times indicates the maximum number of retransmissions for this contention-based PUSCH or RACH. The rollback instruction indicates whether to execute the 4-step RACH process after the competition-based PUSCH fails; as well as Rollback time represents the rollback duration value when the 4-step RACH process starts after the competition-based PUSCH fails.

4. The method of claim 1, wherein, This configuration is received via System Information Block (SIB), Radio Resource Control (RRC) signaling, Media Access Control (MAC) Control Element (CE), or Downlink Control Information (DCI).

5. The method of claim 3, wherein, The enable indicator is configured to the first value, indicating that the one or more retransmissions of the contention-based PUSCH are enabled, and the one or more retransmissions of the contention-based PUSCH are executed on one of the following events: Event: No response message corresponding to the contention-based PUSCH is received before the timer configured for the device to receive the response message expires, and the configured timer expires; Event: The race resolution identifier (ID) for this response message was not correctly received within the race resolution window; Event: Before the timer configured for the device expires, no response message corresponding to the contention resolution ID for the contention-based PUSCH, Dynamic Uplink (UL) Grant, or Downlink (DL) Allocation is received or correctly received from the network node, the timer being used to receive the response message; and Event: Within the configuration window or contention resolution window, the UE does not receive or correctly receives from the network node the response message corresponding to the contention-based PUSCH, dynamic uplink (UL) grant, or downlink (DL) allocation, and the configuration window or contention resolution window is used for the UE to receive the response message.

6. The method of claim 3, wherein, The enable indicator is configured to the first value, indicating that the one or more retransmissions of the RACH are enabled, and the method further includes: The processor increments the total number of retransmissions based on the contention-based PUSCH by 1 before executing the one or more retransmissions of the RACH; and The processor can then indicate a random access problem to the upper layer, or determine that the random access procedure has not been successfully completed when the counter value reaches the maximum number of times.

7. The method of claim 3, wherein, The one or more contention-based PUSCH transmissions are performed via a HARQ process associated with uplink (UL) authorization, which is determined for at least one of the initial transmissions and the one or more contention-based PUSCH retransmissions, and occurs in at least one of the following events: Event: The UL authorization is configured, and the enable indicator is set to the first value; Event: A failure indication for the contention-based PUSCH of the initial transmission was received; Event: The retransmission timer did not expire after the start of the contention-based PUSCH for the initial transmission; Event: The total number of retransmissions for this one or more contention-based PUSCHs did not reach the maximum number or did not reach any other value less than or equal to the maximum number; Event: The total number of transmissions (including the initial transmission and the one or more retransmissions) of the contention-based PUSCH did not reach the maximum number or did not reach any other value less than or equal to the maximum number.

8. The method of claim 1, wherein, The timing for selecting one or more competition-based PUSCH resources includes: One or more PUSCH opportunities are randomly selected from multiple PUSCH resource opportunities configured for this competition-based PUSCH.

9. The method of claim 8, further comprising: The processor determines one or more uplink (UL) grants for the one or more retransmissions of the contention-based PUSCH during the selected one or more PUSCH timings.

10. The method of claim 3, further comprising: After all the initial transmissions and the one or more retransmissions based on the contention-based PUSCH have ended, the processor starts or restarts the contention resolution timer by adding the first sign of the round-trip time (RTT) between the device and the network node, wherein the RTT is set to a non-zero value when the network node is a non-terrestrial network node, or to a zero value when the network node is a terrestrial network node. The processor determines that the contention-based PUSCH has been successfully completed and that the contention associated with the contention-based PUSCH has been successfully resolved if one of the following events occurs: First event: The contention-based PUSCH contains a Media Access Control (MAC) control element (CE) with a Cell Radio Network Temporary Identifier (C-RNTI), and a Physical Downlink Control Channel (PDCCH) transmission containing a new transport UL license for that C-RNTI is received; and Second event: The contention-based PUSCH contains a Common Control Channel (CCCH) Service Data Unit (SDU), and a PDCCH transmission for the contention-based RNTI (CB-RNTI) configured for the device is received, and the following conditions are met: MAC Protocol Data Unit (PDU) successfully decoded; The race-resolver timer stopped because the MAC PDU was successfully decoded; The MAC PDU contains a MAC CE with the UE contention resolution identifier; and The UE contention resolution identifier in the MAC CE is consistent with the identifier transmitted by the CCCH SDU in the contention-based PUSCH; and The processor determines that the contention resolution related to the contention-based PUSCH is unsuccessful if either of the conditions is not met in the second event.

11. The method of claim 3, further comprising: The processor determines, in the event of the race resolution timer expiring, that the race resolution associated with the race-based PUSCH was unsuccessful. When the contention resolution is determined to be unsuccessful, the processor increments the total number of retransmissions counter for the one or more contention-based PUSCHs by 1. The processor determines that the contention-based PUSCH has failed to complete when the counter value reaches the maximum number of times. as well as The processor sends a RACH preamble to the network node after the backoff time when the backoff indication indicates that the four-step RACH procedure needs to be executed after the contention-based PUSCH fails.

12. The method of claim 10, further comprising performing at least one of the following after determining that the competition-based PUSCH has been successfully completed: The processor discards any contention-free random access that is explicitly indicated for the initial transmission and the one or more retransmissions based on the contention-based PUSCH. The processor refreshes the HARQ buffers used for the initial transfer and the contention-based PUSCH-based retransmissions of the one or more retransmissions; and The processor then instructs the upper layer of the device's Media Access Control (MAC) entity that the contention-based PUSCH has been successfully completed.

13. The method of claim 1, further comprising: The processor determines the transmit power of the one or more transmissions of the contention-based PUSCH based on the target receive power of the contention-based PUSCH and the reference signal power of the downlink (DL) reference signal (RS) associated with the one or more transmissions of the contention-based PUSCH.

14. A method comprising: The network node's processor sends a configuration to the device, wherein the configuration includes multiple parameters related to one or more transmissions based on a contention-based Physical Uplink Shared Channel (PUSCH) or Random Access Channel (RACH); and The processor receives the one or more transmissions of the contention-based PUSCH or the RACH from the device at one or more contention-based PUSCH resource times or one or more RACH resource times.

15. The method of claim 14, wherein, The one or more transmissions of the contention-based PUSCH or RACH include at least one initial transmission and one or more retransmissions of the contention-based PUSCH or RACH, and are received before or after a time window for sending a response message corresponding to the contention-based PUSCH or RACH to the device.

16. The method of claim 14, wherein, These parameters include at least one of the following: An enable indicator with a first value indicates that the one or more retransmissions of the contention-based PUSCH or the RACH are enabled, or an enable indicator with a second value indicates that the one or more retransmissions of the contention-based PUSCH or the RACH are not enabled. The first timer value represents the initial value of the retransmission timer, in periods, for the length of two consecutive retransmissions between the one or more retransmissions of the contention-based PUSCH or the RACH. The second timer value represents the initial value of the contention resolution timer used to monitor the length of the response message corresponding to the contention-based PUSCH or RACH. Hybrid Automatic Repeat Request (HARQ) process identifier (ID) offset used for the one or more retransmissions of the contention-based PUSCH; The offset at the start of the retransmission timer; The third timer value represents the value of the maximum retransmission timer for the one or more retransmission lengths used for the contention-based PUSCH or the RACH, in periods. Maximum number of times, representing the maximum number of retransmissions for this contention-based PUSCH or RACH; The rollback instruction indicates whether to execute the 4-step RACH process after the competition-based PUSCH fails; as well as Rollback time represents the value of the rollback duration at the start of the 4-step RACH process after the competition-based PUSCH fails.

17. The method of claim 14, wherein, This configuration is transmitted via System Information Block (SIB), Radio Resource Control (RRC) signaling, Media Access Control (MAC) Control Element (CE), or Downlink Control Information (DCI).

18. An apparatus comprising: A transceiver that communicates wirelessly with network nodes during operation; as well as A processor communicatively connected to the transceiver enables the processor to perform the following operations during operation: The transceiver receives configuration from the network node, wherein the configuration includes multiple parameters related to one or more transmissions of the contention-based Physical Uplink Shared Channel (PUSCH) or Random Access Channel (RACH); Based on this configuration, select one or more contention-based PUSCH resource opportunities or one or more RACH resource opportunities; and The transceiver performs the one or more contention-based PUSCH or RACH transmissions to the network node on one or more contention-based PUSCH resource opportunities or one or more RACH resource opportunities.

19. The apparatus of claim 18, wherein, The one or more transmissions of the contention-based PUSCH or the RACH include at least one initial transmission and one or more retransmissions of the contention-based PUSCH or the RACH, and are performed by the network node before or after a time window for monitoring response messages corresponding to the contention-based PUSCH or the RACH.

20. The apparatus of claim 18, wherein, These parameters include at least one of the following: An enable indicator with a first value indicates that the one or more retransmissions of the contention-based PUSCH or the RACH are enabled, or an enable indicator with a second value indicates that the one or more retransmissions of the contention-based PUSCH or the RACH are not enabled. The first timer value represents the initial value of the retransmission timer, in periods, for the length of two consecutive retransmissions between the one or more retransmissions of the contention-based PUSCH or the RACH. The second timer value represents the initial value of the contention resolution timer used to monitor the length of the response message corresponding to the contention-based PUSCH or RACH. Hybrid Automatic Repeat Request (HARQ) process identifier (ID) offset used for the one or more retransmissions of the contention-based PUSCH; The offset at the start of the retransmission timer; The third timer value represents the value of the maximum retransmission timer for the one or more retransmission lengths used for the contention-based PUSCH or the RACH, in periods. Maximum number of times, representing the maximum number of retransmissions for this contention-based PUSCH or RACH; The rollback instruction indicates whether to execute the 4-step RACH process after the competition-based PUSCH fails; as well as Rollback time represents the value of the rollback duration at the start of the 4-step RACH process after the competition-based PUSCH fails.

Images