Patent Description:
These systems may be capable of supporting communication with multiple users by sharing available system resources. A wireless multiple-access communications system may include a number of base stations (BSs), each simultaneously supporting communications for multiple communication devices, which may be otherwise known as user equipment (UE).

A UE may synchronize to a network by performing a random access procedure, including the exchange of a number of messages (e.g., <NUM>) between the UE and a BS. After the UE transmits a random access message (also referred to a as "message A" or "msgA"), the UE monitors within a random access response window for a random access response message (also referred to as "message B" or "msgB") from the BS. The msgB includes PDCCH and physical downlink shared channel (PDSCH) portions. The BS seeks the decoding status of msgB at the UE (i.e., whether the UE was able to decode msgB) in order to determine whether msgB should be retransmitted or not. However, using a separate message to convey uplink resource allocation information for the UE to use in transmitting a decoding status adds an undesirable signaling overhead.

Thus, there is a need to handle random access procedures in a manner that is efficient and reduces signaling overhead, as well as accommodates different connection states and flexible channel structure.

<NPL>) relates to a discussion on <NUM>-step RACH procedure and in particular to HARQ (hybrid automatic repeat request) for MsgB (Message B) reception. It is proposed that "PUCCH resource for HARQ-ACK can be indicated in either PDCCH or PDSCH".

<NPL>) is directed to a <NUM>-step RACH procedure feature lead summary and in particular to a HARQ-Operation for MsgB. For MsgB the PUCCH resource for HARQ-ACK can be indicated in either PDCCH or PDSCH, or the PUCCH resource for HARQ-ACK can be indicated in PDCCH, PDSCH, in addition to implicitly derivation.

<NPL>) relates to Msg2 payload contents for <NUM>-step RACH. In particular, for the Msg2 of <NUM>-step RACH, the following information should be included as part of the failure response to trigger the payload retransmission: RAP ID, TA Command, UL grant, TC-RNTI and HARQ information (maybe merged to UL grant).

Embodiments of the present invention are defined in the appended independent claims relating to a user terminal or a base station, while optional aspects of the embodiments are defined in the dependent claims. In similar fashion, while exemplary embodiments may be discussed below as device, system, or method embodiments, it should be understood that such exemplary embodiments can be implemented in various devices, systems, and methods.

This disclosure relates generally to wireless communications systems, also referred to as wireless communications networks. In various embodiments, the techniques and apparatus may be used for wireless communication networks such as code division multiple access (CDMA) networks, time division multiple access (TDMA) networks, frequency division multiple access (FDMA) networks, orthogonal FDMA (OFDMA) networks, single-carrier FDMA (SC-FDMA) networks, LTE networks, Global System for Mobile Communications (GSM) networks, <NUM>th Generation (<NUM>) or new radio (NR) networks, as well as other communications networks. As described herein, the terms "networks" and "systems" may be used interchangeably.

An OFDMA network may implement a radio technology such as evolved UTRA (E-UTRA), Institute of Electrical and Electronics Engineers (IEEE) <NUM>, IEEE <NUM>, IEEE <NUM>, flash-OFDM and the like. UTRA, E-UTRA, and GSM are part of universal mobile telecommunication system (UMTS). 3GPP long term evolution (LTE) is a 3GPP project which was aimed at improving the UMTS mobile phone standard.

In particular, <NUM> networks contemplate diverse deployments, diverse spectrum, and diverse services and devices that may be implemented using an OFDM-based unified, air interface. In order to achieve these goals, further enhancements to LTE and LTE-A are considered in addition to development of the new radio technology for <NUM> NR networks. The <NUM> NR will be capable of scaling to provide coverage (<NUM>) to a massive Internet of things (IoTs) with an ultra-high density (e.g., ~<NUM> nodes/km<NUM>), ultra-low complexity (e.g., ~<NUM> of bits/sec), ultra-low energy (e.g., ~<NUM>+ years of battery life), and deep coverage with the capability to reach challenging locations; (<NUM>) including mission-critical control with strong security to safeguard sensitive personal, financial, or classified information, ultra-high reliability (e.g., ~<NUM>% reliability), ultra-low latency (e.g., ~ <NUM>), and users with wide ranges of mobility or lack thereof; and (<NUM>) with enhanced mobile broadband including extreme high capacity (e.g., ~ <NUM> Tbps/km<NUM>), extreme data rates (e.g., multi-Gbps rate, <NUM>+ Mbps user experienced rates), and deep awareness with advanced discovery and optimizations.

The <NUM> NR may be implemented to use optimized OFDM-based waveforms with scalable numerology and transmission time interval (TTI); having a common, flexible framework to efficiently multiplex services and features with a dynamic, low-latency time division duplex (TDD)/frequency division duplex (FDD) design; and with advanced wireless technologies, such as massive multiple input, multiple output (MIMO), robust millimeter wave (mmWave) transmissions, advanced channel coding, and device-centric mobility. Scalability of the numerology in <NUM> NR, with scaling of subcarrier spacing, may efficiently address operating diverse services across diverse spectrum and diverse deployments. For example, in various outdoor and macro coverage deployments of less than <NUM> FDD/TDD implementations, subcarrier spacing may occur with <NUM>, for example over <NUM>, <NUM>, <NUM>, and the like bandwidth (BW). For other various outdoor and small cell coverage deployments of TDD greater than <NUM>, subcarrier spacing may occur with <NUM> over <NUM>/<NUM> BW. For other various indoor wideband implementations, using a TDD over the unlicensed portion of the <NUM> band, the subcarrier spacing may occur with <NUM> over a <NUM> BW. Finally, for various deployments transmitting with mmWave components at a TDD of <NUM>, subcarrier spacing may occur with <NUM> over a <NUM> BW.

The present application describes mechanisms to implement a scalable PUCCH resource configuration for two-step RACH by signaling PUCCH configuration information to a UE via multiple mechanisms. The PUCCH configuration information is then used for transmitting a HARQ message. In some embodiments multiple PUCCH resource scheduling approaches are used to provide flexibility at a UE to obtain the PUCCH resource scheduling, with a tiered hierarchy of preference in which signaled PUCCH resource scheduling to use.

For example, a UE may receive a system information message (or radio resource control (RRC) message, referred to jointly herein as simply system information message for simplicity of discussion) that includes default PUCCH resource configuration information (e.g., a limited set of semi-persistent configurations), as well as one or more indications of what type of downlink control information (DCI) format may be signaled in PDCCH of a RACH response message (msgB) later from a BS. After the UE transmits a RACH message (msgA) to the BS, the BS responds with msgB that includes a PUCCH resource indicator in a DCI of PDCCH, as well as another PUCCH resource indicator in a PDSCH payload of the msgB.

According to the present invention, the UE, upon receiving msgB, attempts to decode PDCCH and then PDSCH. If the UE is successful in decoding both PDCCH and PDSCH, then the UE will use the PUCCH resource configuration indicated in the PDSCH payload. If, instead, the UE is successful in decoding PDCCH but not PDSCH of the msgB, then the UE will use the PUCCH resource configuration indicated in the PDCCH DCI. Where the UE is not successful in decoding PDCCH, the UE may use the default PUCCH resource configuration information. With the corresponding PUCCH resource configuration information obtained (either from PDSCH, PDCCH, or default from system information), the UE signals a HARQ message (ACK/NACK) to the BS based on whether receiving msgB was successful or not.

Aspects of the present application provide several benefits. For example, using this PUCCH resource configuration information signaling approach accommodates different RRC states and msgB decoding outcomes, as well as supports flexibility in the msgB channel structure. Further, embodiments of the present disclosure reduce signaling overhead for PUCCH resource configuration by not requiring a separate channel from the BS after msgB is sent. Scalable resource configuration for PUCCH is also supported, and embodiments of the present disclosure also comply with PUCCH formats defined in existing releases. Additional features and benefits of the present disclosure are set forth in the following description.

<FIG> illustrates a wireless communication network <NUM> according to some embodiments of the present disclosure. The network <NUM> may be a <NUM> network. The network <NUM> includes a number of base stations (BSs) <NUM> (individually labeled as 105a, 105b, 105c, 105d, 105e, and 105f) and other network entities. A BS <NUM> may be a station that communicates with UEs <NUM> and may also be referred to as an evolved node B (eNB), a next generation eNB (gNB), an access point, and the like. Each BS <NUM> may provide communication coverage for a particular geographic area. In 3GPP, the term "cell" may refer to this particular geographic coverage area of a BS <NUM> and/or a BS subsystem serving the coverage area, depending on the context in which the term is used.

The UEs <NUM> are dispersed throughout the wireless network <NUM>, and each UE <NUM> may be stationary or mobile. A UE <NUM> may also be referred to as a terminal, a mobile station, a subscriber unit, a station, or the like. A UE <NUM> may be a cellular phone, a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a tablet computer, a laptop computer, a cordless phone, a wireless local loop (WLL) station, or the like. In one aspect, a UE <NUM> may be a device that includes a Universal Integrated Circuit Card (UICC). In another aspect, a UE may be a device that does not include a UICC. In some aspects, the UEs <NUM> that do not include UICCs may also be referred to as IoT devices or internet of everything (IoE) devices. The UEs 115a-115d are examples of mobile smart phone-type devices accessing network <NUM>. A UE <NUM> may also be a machine specifically configured for connected communication, including machine type communication (MTC), enhanced MTC (eMTC), narrowband IoT (NB-IoT) and the like. The UEs 115e-<NUM> are examples of various machines configured for communication that access the network <NUM>. A UE <NUM> may be able to communicate with any type of the BSs, whether macro BS, small cell, or the like. In <FIG>, a lightning bolt (e.g., communication links) indicates wireless transmissions between a UE <NUM> and a serving BS <NUM>, which is a BS designated to serve the UE <NUM> on the downlink and/or uplink, or desired transmission between BSs, and backhaul transmissions between BSs.

The BSs <NUM> may also communicate with a core network. The core network may provide user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. At least some of the BSs <NUM> (e.g., which may be an example of a gNB or an access node controller (ANC)) may interface with the core network through backhaul links (e.g., NG-C, NG-U, etc.) and may perform radio configuration and scheduling for communication with the UEs <NUM>. In various examples, the BSs <NUM> may communicate, either directly or indirectly (e.g., through core network), with each other over backhaul links (e.g., X1, X2, etc.), which may be wired or wireless communication links.

The network <NUM> may also support mission critical communications with ultra-reliable and redundant links for mission critical devices, such as the UE 115e, which may be a drone. Redundant communication links with the UE 115e may include links from the macro BSs 105d and 105e, as well as links from the small cell BS 105f. Other machine type devices, such as the UE 115f (e.g., a thermometer), the UE <NUM> (e.g., smart meter), and UE <NUM> (e.g., wearable device) may communicate through the network <NUM> either directly with BSs, such as the small cell BS 105f, and the macro BS 105e, or in multi-hop configurations by communicating with another user device which relays its information to the network, such as the UE 115f communicating temperature measurement information to the smart meter, the UE <NUM>, which is then reported to the network through the small cell BS 105f. The network <NUM> may also provide additional network efficiency through dynamic, low-latency TDD/FDD communications, such as in a vehicle-to-vehicle (V2V) communication.

In some implementations, the network <NUM> utilizes OFDM-based waveforms for communications. An OFDM-based system may partition the system BW into multiple (K) orthogonal subcarriers, which are also commonly referred to as subcarriers, tones, bins, or the like. Each subcarrier may be modulated with data. In some instances, the subcarrier spacing between adjacent subcarriers may be fixed, and the total number of subcarriers (K) may be dependent on the system BW. The system BW may also be partitioned into subbands. In other instances, the subcarrier spacing and/or the duration of TTIs may be scalable.

In an embodiment, the BSs <NUM> may assign or schedule transmission resources (e.g., in the form of time-frequency resource blocks (RB)) for downlink (DL) and uplink (UL) transmissions in the network <NUM>. DL refers to the transmission direction from a BS <NUM> to a UE <NUM>, whereas UL refers to the transmission direction from a UE <NUM> to a BS <NUM>. The communication may be in the form of radio frames. A radio frame may be divided into a plurality of subframes or slots, for example, about <NUM>. Each slot may be further divided into mini-slots. In a FDD mode, simultaneous UL and DL transmissions may occur in different frequency bands. For example, each subframe includes a UL subframe in a UL frequency band and a DL subframe in a DL frequency band. In a TDD mode, UL and DL transmissions occur at different time periods using the same frequency band. For example, a subset of the subframes (e.g., DL subframes) in a radio frame may be used for DL transmissions and another subset of the subframes (e.g., UL subframes) in the radio frame may be used for UL transmissions.

The DL subframes and the UL subframes may be further divided into several regions. For example, each DL or UL subframe may have pre-defined regions for transmissions of reference signals, control information, and data. Reference signals are predetermined signals that facilitate the communications between the BSs <NUM> and the UEs <NUM>. For example, a reference signal may have a particular pilot pattern or structure, where pilot tones may span across an operational BW or frequency band, each positioned at a pre-defined time and a pre-defined frequency. For example, a BS <NUM> may transmit cell specific reference signals (CRSs) and/or channel state information - reference signals (CSI-RSs) to enable a UE <NUM> to estimate a DL channel. Similarly, a UE <NUM> may transmit sounding reference signals (SRSs) to enable a BS <NUM> to estimate a UL channel. Control information may include resource assignments and protocol controls. Data may include protocol data and/or operational data. In some embodiments, the BSs <NUM> and the UEs <NUM> may communicate using self-contained subframes. A self-contained subframe may include a portion for DL communication and a portion for UL communication. A self-contained subframe may be DL-centric or UL-centric. A DL-centric subframe may include a longer duration for DL communication than for UL communication. A UL-centric subframe may include a longer duration for UL communication than for UL communication.

In an embodiment, the network <NUM> may be an NR network deployed over a licensed spectrum. The BSs <NUM> may transmit synchronization signals (e.g., including a primary synchronization signal (PSS) and a secondary synchronization signal (SSS)) in the network <NUM> to facilitate synchronization. The BSs <NUM> may broadcast system information associated with the network <NUM> (e.g., including a master information block (MIB), remaining system information (RMSI), and other system information (OSI)) to facilitate initial network access. In some instances, the BSs <NUM> may broadcast the PSS, the SSS, and/or the MIB in the form of synchronization signal block (SSBs) over a physical broadcast channel (PBCH) and may broadcast the RMSI and/or the OSI over a physical downlink shared channel (PDSCH).

In an embodiment, a UE <NUM> attempting to access the network <NUM> may perform an initial cell search by detecting a PSS from a BS <NUM>. The PSS may enable synchronization of period timing and may indicate a physical layer identity value. The UE <NUM> may then receive a SSS. The SSS may enable radio frame synchronization, and may provide a cell identity value, which may be combined with the physical layer identity value to identify the cell. The PSS and the SSS may be located in a central portion of a carrier or any suitable frequencies within the carrier.

After receiving the PSS and SSS, the UE <NUM> may receive a MIB. The MIB may include system information for initial network access and scheduling information for RMSI and/or OSI. After decoding the MIB, the UE <NUM> may receive RMSI and/or OSI. The RMSI and/or OSI may include radio resource control (RRC) information related to random access channel (RACH) procedures, paging, control resource set (CORESET) for physical downlink control channel (PDCCH) monitoring, physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), power control, and SRS.

After obtaining the MIB, the RMSI and/or the OSI, the UE <NUM> may perform a random access procedure to establish a connection with the BS <NUM>. In a four-step random access procedure, the UE <NUM> may transmit a random access preamble and the BS <NUM> may respond with a random access response. The random access response (RAR) may include a detected random access preamble identifier (ID) corresponding to the random access preamble, timing advance (TA) information, a UL grant, a temporary cell-radio network temporary identifier (C-RNTI), and/or a backoff indicator. Upon receiving the random access response, the UE <NUM> may transmit a connection request to the BS <NUM> and the BS <NUM> may respond with a connection response. The connection response may indicate a contention resolution. In some examples, the random access preamble, the RAR, the connection request, and the connection response may be referred to as a message <NUM> (MSG <NUM>), a message <NUM> (MSG <NUM>), a message <NUM> (MSG <NUM>), and a message <NUM> (MSG <NUM>), respectively. According to embodiments of the present disclosure, the random access procedure may be a two-step random access procedure, where the UE <NUM> may transmit a random access preamble and a connection request in a single transmission and the BS <NUM> may respond by transmitting a random access response and a connection response in a single transmission. The combined random access preamble and connection request in the two-step random access procedure may be referred to as a message A (msgA). The combined random access response and connection response in the two-step random access procedure may be referred to as a message B (msgB).

After establishing a connection, the UE <NUM> and the BS <NUM> can enter an operational state, where operational data may be exchanged. For example, the BS <NUM> may schedule the UE <NUM> for UL and/or DL communications. The BS <NUM> may transmit UL and/or DL scheduling grants to the UE <NUM> via a PDCCH. The BS <NUM> may transmit a DL communication signal to the UE <NUM> via a PDSCH according to a DL scheduling grant. The UE <NUM> may transmit a UL communication signal to the BS <NUM> via a PUSCH and/or PUCCH according to a UL scheduling grant.

In some embodiments, the BS <NUM> and the UE <NUM> may employ hybrid automatic request (HARQ) PUCCH resource scheduling techniques for RACH communications to reduce overhead and latency, with signaling of resources for HARQ described in greater detail below. For example, in some embodiments multiple PUCCH resource scheduling approaches are used to provide flexibility at a UE to obtain the PUCCH resource scheduling. One of the PUCCH scheduling approaches utilizes system information.

When the BS <NUM> broadcasts system information associated with the network (e.g., prior to a RACH procedure by the UE, or an updated RACH procedure, etc.), the BS <NUM> may include according to embodiments of the present disclosure various configuration parameters relating to a RACH procedure. For example, the system information may include default PUCCH resource configuration information that the UE may use when other sources of PUCCH resource configuration information, such as in a DCI or PDSCH (as discussed further below), are not available due to decoding failure. The default PUCCH resource configuration information may include, for example, a default resource indicator that serves as an index into a look-up table. The look-up table may provide most or all of the PUCCH parameters necessary for the PUCCH resource configuration for a HARQ transmission (whether ACK or NACK). The look-up table, itself, may be conveyed with the system information message as well, or configured previously at the UE and the BS. Further, some of the transmission parameters may be configurable in combination with the information from the system information message, such as cyclic shift. Thus, most of the PUCCH parameters are obtained from the look-up table, while the cyclic shift may be determined based on a parameter msgA that the UE sends at the start of the RACH procedure (e.g., a resource index like the preamble sequence index when combined with the cyclic shift identified from the look-up table entry).

Another example of one of the PUCCH scheduling approaches utilizes providing a resource indicator in DCI for a PDCCH part of a msgB from the BS <NUM>. Scheduling/communicating the PUCCH resources via the PDCCH of msgB may be utilized in situations where PUCCH resource indication is not available via the PDSCH of msgB (e.g., due to a decoding failure of PDSCH, etc.). Further, PUCCH resource indication may take priority over the default indication based upon the system information.

In the PUCCH resource indication approach, the system information message may also (or alternatively) include a bit length indicator (also referred to herein as a variable, N, for purposes of discussion) that identifies what the size (in bits) a resource indicator will be that is included in a msgB's DCI (in PDCCH). The receiving UE <NUM> may use this value N to recognize the location of the resource indicator in PDCCH's DCI when the UE <NUM> receives a msgB from the BS <NUM>. For example, if the PUCCH resources for HARQ are scheduled from a shortened look-up table (e.g., <NUM> rows instead of <NUM> rows), the DCI may utilize the three bits for the PUCCH resource indicator that is currently used in DCI format 1_0 (as an example). As another example, if the PUCCH resources are scheduled from a larger look-up table (e.g., <NUM> rows), other fields of a DCI, such as of DCI format 1_0, may be modified to carry information relating to the resource indicator instead (or a new, custom DCI format may be implemented that is different from existing formats like format 1_0). Again, the look-up table may provide most or all of the PUCCH parameters the UE <NUM> will use to send a HARQ transmission to the BS <NUM>.

The PUCCH resource indication approach may also utilize additional information to accommodate configuration options that exceed a DCI field size available for PUCCH resource indication. For example, the system information message may also include an identification that will trigger the UE <NUM> to use a resource offset while determining PUCCH resources for a HARQ message during a RACH procedure. For example, the system information message may identify a configuration parameter, or a combination of configuration parameters, that will be used in a subsequent RACH procedure involving the UE <NUM>. Some example configuration parameters include the msgA preamble sequence identifier, msgA preamble occasion index, msgA PUSCH occasion, msgB-RNTI, CORESET/search space index for msgB PDCCH, etc., or some combination of parameters as identified by the system information message. Such configuration parameters may be used in combination with a resource indicator to add a resource offset to the PUCCH resources determined from indexing into a look-up table (e.g., using the resource indicator). As a result, a look-up table larger than existing tables (e.g., with more than <NUM> entries) may not be necessary, as the resource offset provides further modification to the existing entries to provide the additional resource scheduling options for the UE <NUM>.

Another example of PUCCH scheduling approaches in accordance with the present invention utilizes PUCCH resource indication in the PDSCH of the msgB. For example, where the UE <NUM> receiving msgB from BS <NUM> during a two-step RACH procedure is able to decode PDCCH and PDSCH, the UE <NUM> will prioritize using the PUCCH resource indication provided in the PDSCH over the other approaches (indication in DCI of PDCCH, and/or default configuration information from the system information message). This allows the PUCCH resources to be dynamically configured by RRC protocol, for example, or alternatively hard-coded. For example, dynamic configuration may include the PDSCH signaling a set a configuration parameters that have been dynamically selected, including for example starting location of physical resource blocks (PRB) or PRB offset in the frequency domain, intra-slot frequency hopping, second hop PRB offset, first symbol, number of symbols, initial indices for cyclic shift, number of PRBs, time domain orthogonal cover code (OCC), OCC length, OCC index, inter-slot frequency hopping, additional demodulation reference signal (DMRS) configuration, maximum code rate, number slots, support for π/<NUM> binary phase shift keying (BPSK), and/or support for simultaneous HARQ ACK and CSI, some subset or combination of these, etc. As another example, hard-coded configuration may include utilizing either the longer (e.g., <NUM>-entry) or shorter (e.g., <NUM>-entry) tables as introduced above and discussed further below with respect to <FIG>.

Providing the PUCCH resource indication in the PDSCH of msgB from BS <NUM> may be done with a unicast message to UE <NUM> (generally, targeting one UE that has started a RACH procedure) or multicast message to multiple UEs <NUM> (generally, targeting multiple UEs that have all started a RACH procedure, such as in the same RACH occasion). For the multicast, the payload may include information for each UE <NUM> receiving msgB (specifically PDSCH of msgB) consecutive to the last, so that UE2 follows UE1, UE3 follows UE2, etc. Whether the resource configuration is dynamically configured or hard-coded, using PDSCH for resource indication allows for signaling additional information with the PUCCH resource indication. In addition to the PUCCH resource configuration information, the payload may include an identifier of each UE such as contention resolution identifier, C-RNTI, or both.

Thus, at a high level, the BS <NUM> may signal a variety of PUCCH resource configurations to the UE <NUM> engaged in a RACH procedure that the UE <NUM> may use to transmit an ACK or a NACK in a HARQ message after receipt of msgB. Specifically, in a descending hierarchy of use, the UE <NUM> may first attempt to use the PUCCH resources identified via PDSCH signaling. If that is not available, then the UE <NUM> may then revert to the PUCCH resources identified via PDCCH signaling. If that is also not available, then the UE <NUM> may revert to using the default PUCCH resources identified via earlier system information signaling. These approaches, and their interplay, will be discussed in more detail below with respect to the subsequent figures. According to embodiments of the present disclosure, different RRC states and msgB decoding outcomes may be accommodated, msgB channel structure flexibility is supported, signaling overhead for PUCCH resource configuration is reduced, scalable resource configuration for PUCCH is supported, and compatibility with newer PUCCH format definitions is facilitated.

The network <NUM> may operate over a shared frequency band or an unlicensed frequency band, for example, at about <NUM> gigahertz (GHz), sub-<NUM> or higher frequencies in the mmWave band. The network <NUM> may partition a frequency band into multiple channels, for example, each occupying about <NUM> megahertz (MHz). The BSs <NUM> and the UEs <NUM> may be operated by multiple network operating entities sharing resources in the shared communication medium and may acquire channel occupancy time (COT) in the share medium for communications. A COT may be noncontinuous in time and may refer to an amount of time a wireless node can send frames when it has won contention for the wireless medium. Each COT may include a plurality of transmission slots. A COT may also be referred to as a transmission opportunity (TXOP).

<FIG> illustrates a protocol diagram of a wireless communication method <NUM>, particularly a random access procedure <NUM> with HARQ, between a UE <NUM> (of which UEs <NUM> are examples) and a BS <NUM> (of which BSs <NUM> are examples) according to some embodiments of the present disclosure. The random access procedure <NUM> may include a two-step random access procedure, where the UE <NUM> transmits a random access preamble and a connection request in a single transmission and the BS <NUM> may respond by transmitting a random access response and a connection response in a single transmission. In the two-step random access procedure, the combined random access preamble and connection request may be referred to as a message A (MSG A), while the combined random access response and connection response may be referred to as a message B (MSG B).

At action <NUM>, the BS <NUM> transmits a system information message to the UE <NUM>. The system information message may include various configuration parameters for the subsequent determination of PUCCH resources at the UE <NUM>. For example, the system information message (as relevant to discussion herein - other information is further included in the system information message that is not discussed herein) may include default PUCCH resource configuration information including a default resource indicator, as well as bit length size for a resource indicator signaled via PDCCH DCI, and/or identification of RACH message parameter(s) to use when determining a resource indicator. The system information message may also include one or more look-up tables, or updates to look-up tables stored at the UE <NUM>.

Following transmission of the system information message, the UE <NUM> may initiate a RACH procedure. This may occur when the UE is any of a variety of RRC states, including for example RRC idle/inactive state, or RRC connected. To do so, at action <NUM>, the UE <NUM> transmits msgA to the BS <NUM>. As noted above, msgA may include a combination of the random access preamble and connection request (as well as other information, such as a tracking area update, a scheduling request, and a UE identifier).

At action <NUM>, the BS <NUM> processes the preamble and payload received in the msgA from UE <NUM> from action <NUM>. As part of this processing, for example, the BS <NUM> may dynamically determine one or more PUCCH resources to include in the PDSCH (payload) portion of msgB that the BS <NUM> will send back to UE <NUM>. Further, the BS <NUM> may encode into DCI of the msgB's PDCCH further PUCCH resources for the UE <NUM> to use in the event that decoding of the PDSCH of msgB fails. In addition to the PDCCH and PDSCH resource scheduling information for PUCCH for HARQ messaging, the BS <NUM> may further include other information into the msgB including a detected random access preamble ID, TA information, a C-RNTI, a backoff indicator, and a contention resolution.

At action <NUM>, the BS <NUM> transmits the generated msgB (which includes PUCCH resource indications in PDCCH and PDSCH portions) to the UE <NUM>.

At action <NUM>, the UE <NUM> receives the msgB from BS <NUM> and processes the message. This includes, first, decoding the PDCCH. If successful, the UE <NUM> obtains from the PDCCH the information it needs to decode PDSCH, as well as PUCCH resource scheduling information to use for HARQ messaging in the event that decoding the PDSCH of msgB fails. If the UE <NUM> is also successful in decoding the PDSCH of msgB, then the UE <NUM> will obtain the PUCCH resource scheduling information that BS <NUM> included in PDSCH, and which will take precedence in use for a HARQ message.

At action <NUM>, the UE <NUM> transmits a HARQ message to the BS <NUM>. This may be an ACK if receipt of msgB was successful, or NACK if unsuccessful. For example, if the UE <NUM> was able to decode PDCCH but not PDSCH, according to embodiments of the present disclosure the UE <NUM> may use the PUCCH resource scheduling information it obtained from the DCI of the PDCCH in msgB to transmit a HARQ NACK to the BS <NUM>. Alternatively, if decoding the PDCCH was unsuccessful, the UE <NUM> may instead use the default PUCCH resource scheduling information it obtained from the system information message (e.g., action <NUM> in this example) to transmit a HARQ NACK to the BS <NUM>. As another example, if decoding PDCCH and PDSCH of msgB is successful, the UE <NUM> may use the PUCCH resource scheduling information obtained from the PDSCH to transmit a HARQ ACK to the BS <NUM>. As will be recognized, the UE <NUM> may alternatively use PUCCH resource scheduling information from the PDCCH and/or system information message to transmit a HARQ ACK to the BS <NUM> as well according to embodiments of the present disclosure.

<FIG> is a block diagram of an exemplary UE <NUM> according to embodiments of the present disclosure. The UE <NUM> may be a UE <NUM> discussed above in <FIG> and <FIG>. As shown, the UE <NUM> may include a processor <NUM>, a memory <NUM>, a RACH processing and control module <NUM>, a transceiver <NUM> including a modem subsystem <NUM> and a radio frequency (RF) unit <NUM>, and one or more antennas <NUM>. These elements may be in direct or indirect communication with each other, for example via one or more buses.

The memory <NUM> may include a cache memory (e.g., a cache memory of the processor <NUM>), random access memory (RAM), magnetoresistive RAM (MRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, solid state memory device, hard disk drives, other forms of volatile and non-volatile memory, or a combination of different types of memory. In an embodiment, the memory <NUM> includes a non-transitory computer-readable medium. The memory <NUM> may store, or have recorded thereon, instructions <NUM>. The instructions <NUM> may include instructions that, when executed by the processor <NUM>, cause the processor <NUM> to perform the operations described herein with reference to the UEs <NUM> in connection with embodiments of the present disclosure, for example, aspects of <FIG>, <FIG>, <FIG>, and <FIG>. Instructions <NUM> may also be referred to as program code. The program code may be for causing a wireless communication device (or specific component(s) of the wireless communication device) to perform these operations, for example by causing one or more processors (such as processor <NUM>) to control or command the wireless communication device (or specific component(s) of the wireless communication device) to do so. The terms "instructions" and "code" should be interpreted broadly to include any type of computer-readable statement(s). For example, the terms "instructions" and "code" may refer to one or more programs, routines, sub-routines, functions, procedures, etc. "Instructions" and "code" may include a single computer-readable statement or many computer-readable statements.

The RACH processing and control module <NUM> may be implemented via hardware, software, or combinations thereof. For example, RACH processing and control module <NUM> may be implemented as a processor, circuit, and/or instructions <NUM> stored in the memory <NUM> and executed by the processor <NUM>. In some examples, the RACH processing and control module <NUM> can be integrated within the modem subsystem <NUM>. For example, the RACH processing and control module <NUM> can be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the modem subsystem <NUM>.

The RACH processing and control module <NUM> may be used for various aspects of the present disclosure, for example, aspects of <FIG>, <FIG>, <FIG>, and <FIG>. The RACH processing and control module <NUM> is configured to communicate with other components of the UE <NUM> to transmit of one or more RACH messages (e.g., msgA), receive one or more RACH messages (e.g., msgB), receive and determine PUCCH resource scheduling information from one or more of system information messaging, PDCCH, and/or PDSCH of msgB messaging, perform HARQ processing on one or more RACH messages (e.g., msgB), transmit an ACK/NACK for one or more RACH messages (e.g., msgB) using determined PUCCH resources according to embodiments of the present disclosure, determine whether a timer has expired, start a timer, cancel a timer, stop a timer, determine whether a transmission counter has reached a threshold, reset a transmission counter, restart a random access procedure, trigger RLF, and/or perform other functionalities related to the RACH procedures of a UE described in the present disclosure.

As shown, the transceiver <NUM> may include the modem subsystem <NUM> and the RF unit <NUM>. The transceiver <NUM> can be configured to communicate bi-directionally with other devices, such as the BSs <NUM>. The modem subsystem <NUM> may be configured to modulate and/or encode the data from the memory <NUM>, and/or the RACH processing and control module <NUM> according to a modulation and coding scheme (MCS) (e.g., a low-density parity check (LDPC) coding scheme, a turbo coding scheme, a convolutional coding scheme, a digital beamforming scheme, etc.). The RF unit <NUM> may be configured to process (e.g., perform analog to digital conversion or digital to analog conversion, etc.) modulated/encoded data (e.g., UL data bursts, RRC messages, RACH message(s) (e.g., msgA), ACK/NACKs for DL data bursts) from the modem subsystem <NUM> (on outbound transmissions) or of transmissions originating from another source such as a UE <NUM> or a BS <NUM>. The RF unit <NUM> may be further configured to perform analog beamforming in conjunction with the digital beamforming. Although shown as integrated together in transceiver <NUM>, the modem subsystem <NUM> and the RF unit <NUM> may be separate devices that are coupled together at the UE <NUM> to enable the UE <NUM> to communicate with other devices.

The RF unit <NUM> may provide the modulated and/or processed data (e.g., data packets or, more generally, data messages that may contain one or more data packets and other information) to the antennas <NUM> for transmission to one or more other devices. The antennas <NUM> may further receive data messages transmitted from other devices. The antennas <NUM> may provide the received data messages for processing and/or demodulation at the transceiver <NUM>. The transceiver <NUM> may provide the demodulated and decoded data (e.g., system information message(s), RACH message(s) (e.g., msgB including PUCCH resource scheduling information), DL/UL scheduling grants, DL data bursts, RACH messages, RRC messages, ACK/NACK requests) to the RACH processing and control module <NUM> for processing. The antennas <NUM> may include multiple antennas of similar or different designs in order to sustain multiple transmission links. The RF unit <NUM> may configure the antennas <NUM>.

In an embodiment, the UE <NUM> can include multiple transceivers <NUM> implementing different RATs (e.g., NR and LTE). In an embodiment, the UE <NUM> can include a single transceiver <NUM> implementing multiple RATs (e.g., NR and LTE). In an embodiment, the transceiver <NUM> can include various components, where different combinations of components can implement different RATs.

<FIG> is a block diagram of an exemplary BS <NUM> according to embodiments of the present disclosure. The BS <NUM> may be a BS <NUM> as discussed above in <FIG> and <FIG>. As shown, the BS <NUM> may include a processor <NUM>, a memory <NUM>, a RACH processing and control module <NUM>, a transceiver <NUM> including a modem subsystem <NUM> and a RF unit <NUM>, and one or more antennas <NUM>. These elements may be in direct or indirect communication with each other, for example via one or more buses.

The instructions <NUM> may include instructions that, when executed by the processor <NUM>, cause the processor <NUM> to perform operations described herein, for example, aspects of <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>.

The RACH processing and control module <NUM> may be implemented via hardware, software, or combinations thereof. For example, the RACH processing and control module <NUM> may be implemented as a processor, circuit, and/or instructions <NUM> stored in the memory <NUM> and executed by the processor <NUM>. In some examples, the RACH processing and control module <NUM> can be integrated within the modem subsystem <NUM>. For example, the RACH processing and control module <NUM> can be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the modem subsystem <NUM>.

The RACH processing and control module <NUM> may be used for various aspects of the present disclosure, for example, aspects of <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. The RACH processing and control module <NUM> is configured to include transmit or retransmit one or more RACH messages having a timing advance (TA) command to a UE (e.g., the UEs <NUM> and/or <NUM>), receive an ACK/NACK for one or more of the transmitted or retransmitted RACH messages, transmit one or more DL scheduling grants to a UE indicating DL resources (e.g., time-frequency resources), transmit DL data to the UE, transmit one or more UL scheduling grants to the UE indicating UL resources, receive UL data from the UE, etc..

The RACH processing and control module <NUM> is configured to communicate with other components of the BS <NUM> to receive of one or more RACH messages (e.g., msgA), include PUCCH resource scheduling information into system information messages and/or RACH messages (e.g., msgB), transmit one or more system information messages, transmit one or more RACH messages (e.g., msgB), perform HARQ processing on one or more RACH messages (e.g., msgB), receive an ACK/NACK for one or more RACH messages (e.g., msgB), determine whether a timer has expired, start a timer, cancel a timer, determine whether a transmission counter has reached a threshold, reset a transmission counter, terminate a random access procedure, and/or perform other functionalities related to the RACH procedures of a BS described in the present disclosure.

As shown, the transceiver <NUM> may include the modem subsystem <NUM> and the RF unit <NUM>. The transceiver <NUM> can be configured to communicate bi-directionally with other devices, such as the UEs <NUM> and/or <NUM> and/or another core network element. The modem subsystem <NUM> may be configured to modulate and/or encode data according to a MCS (e.g., a LDPC coding scheme, a turbo coding scheme, a convolutional coding scheme, a digital beamforming scheme, etc.). The RF unit <NUM> may be configured to process (e.g., perform analog to digital conversion or digital to analog conversion, etc.) modulated/encoded data (e.g., RACH messages (e.g., msgB, etc.), , ACK/NACK requests, DL/UL scheduling grants, DL data, RRC messages, etc.) from the modem subsystem <NUM> (on outbound transmissions) or of transmissions originating from another source, such as a UE <NUM> or <NUM>. The RF unit <NUM> may be further configured to perform analog beamforming in conjunction with the digital beamforming. Although shown as integrated together in transceiver <NUM>, the modem subsystem <NUM> and/or the RF unit <NUM> may be separate devices that are coupled together at the BS <NUM> to enable the BS <NUM> to communicate with other devices.

The RF unit <NUM> may provide the modulated and/or processed data, (e.g., data packets or, more generally, data messages that may contain one or more data packets and other information) to the antennas <NUM> for transmission to one or more other devices. This may include, for example, transmission of information to complete attachment to a network and communication with a camped UE <NUM> or <NUM> according to embodiments of the present disclosure. The antennas <NUM> may further receive data messages transmitted from other devices and provide the received data messages for processing and/or demodulation at the transceiver <NUM>. The transceiver <NUM> may provide the demodulated and decoded data (e.g., RACH message(s) (e.g., msgA), ACK/NACKs for RACH message(s) (e.g., ACK/NACK for msgB), UL data, ACK/NACKs for DL data, etc.) to the RACH processing and control module <NUM> for processing. The antennas <NUM> may include multiple antennas of similar or different designs in order to sustain multiple transmission links.

In an embodiment, the BS <NUM> can include multiple transceivers <NUM> implementing different RATs (e.g., NR and LTE). In an embodiment, the BS <NUM> can include a single transceiver <NUM> implementing multiple RATs (e.g., NR and LTE). In an embodiment, the transceiver <NUM> can include various components, where different combinations of components can implement different RATs.

<FIG> illustrate look-up table formats to be used in identifying PUCCH resources (e.g., using resource indicators as included in msgB and/or system information messages from the BS) in accordance with the present disclosure.

As shown in <FIG>, a look-up table <NUM> consists of multiple rows <NUM>-<NUM>, where each row includes a set of PUCCH configuration parameters including time/frequency resource assignments, indices, etc. As illustrated, for example, look-up table <NUM> includes the parameters index <NUM>, PUCCH format <NUM>, first symbol <NUM>, number of symbols <NUM>, PRB offset <NUM>, and initial cyclic shift index sets <NUM>. In <FIG>'s illustrated example, there are a total of <NUM> rows in the look-up table <NUM>. To signal what row to index into for PUCCH configuration parameters (i.e., PUCCH resource scheduling information), four bits (to uniquely identify all <NUM> rows) may be used in PDCCH signaling as discussed further below.

According to some embodiments of the present disclosure, instead of <NUM> rows a look-up table may have a reduced number of entries. For example, <FIG> illustrates an example look-up table <NUM> with reduced number of entries (as compared to the look-up table <NUM> of <FIG>). In the illustrated example, there are <NUM> total rows identified as rows <NUM>-<NUM> (more or fewer may also be possible and within the scope of this disclosure). The rows <NUM>-<NUM> may be a subset of those rows <NUM>-<NUM> illustrated in table <NUM> of <FIG>, or different. To signal what row to index into for PUCCH configuration parameters in look-up table <NUM>, three bits may be used to uniquely identify all <NUM> rows in PDCCH signaling, as will be discussed further below.

Thus, as discussed in more detail in other aspects of this disclosure, when referencing a look-up table, embodiments of the present disclosure may index (e.g., using some form of resource indicator according to the various embodiments herein) into a specific row of the relevant look-up table - e.g., look-up table <NUM> when the BS <NUM> relies upon a full-sized table, or look-up table <NUM> when relying upon a reduced-size table.

In order to signal the resource indicator information used to index into the look-up table (<NUM>/<NUM>), embodiments of the present disclosure may use a combination of information included in a system information message, DCI in a msgB PDCCH, and/or payload information included in a msgB PDSCH. Several DCI formats are illustrated in <FIG> according to some embodiments of the present disclosure.

For example, <FIG> illustrates an example DCI format <NUM> with multiple fields that may be purposed with conveying a resource indicator for PUCCH configuration parameters according to some embodiments of the present disclosure. For example, DCI format <NUM> repurposes DCI format 1_0 for conveying the PUCCH resource indicator field to identify the PUCCH the UE <NUM> will use for HARQ messaging in response to msgB from BS <NUM>. However, according to embodiments of the present disclosure, the CRC is masked by msgB-RNTI as opposed to C-RNTI as previously used. As illustrated, row <NUM> identifies the PUCCH Resource Indicator, i.e. the PUCCH resource indicator used to index into a look-up table. As identified in row <NUM>, the PUCCH resource indicator is <NUM> bits wide. Thus, the DCI format <NUM> may be used to index into a reduced-entry number look-up table, such as look-up table <NUM> illustrated in <FIG>, since three bits are enough to uniquely identify all eight rows of the table <NUM>.

For indexing into a larger table, such as the look-up table <NUM> illustrated in <FIG> that has <NUM> row entries, a modified DCI format <NUM> as illustrated in <FIG> may be used instead. Like DCI format <NUM>, the CRC is masked by msgB-RNTI instead of C-RNTI.

As illustrated in <FIG>, the DCI format <NUM> modifies and/or repurposes use of several bit fields to signal the PUCCH resource indicator to the UE <NUM>. For example, row <NUM> that traditionally conveys the HARQ process number with four bits, is modified in <FIG> to be optional. When included, the HARQ process number in DCI format <NUM> has a bit width of three. The fourth bit is repurposed for a new field illustrated at row <NUM> as the most significant bit (MSB) for the PUCCH resource indicator. Thus, for a four-bit PUCCH resource indicator, the MSB would be included in this repurposed field. The rest of the four-bit PUCCH resource indicator is included in the LSB for PUCCH resource indicator field illustrated at row <NUM> of <FIG>. This field is repurposed from the PUCCH resource indicator field at row <NUM> of <FIG>, using the three available bits to convey the remaining bits of the four-bit PUCCH resource indicator (i.e., the LSB after the MSB). The UE <NUM>, upon receiving the DCI format <NUM> in a PDCCH, would access both fields and combine them together to form the full PUCCH resource indicator for subsequent indexing into the appropriate row of a look-up table.

Continuing with the other fields of DCI format <NUM>, similar to HARQ process number, the downlink assignment index (DAI) illustrated at row <NUM> is modified to be optional (previously occupying two bits in DCI format 1_0). This field, as well as the now-optional HARQ process number, may instead be repurposed to convey other information (if any). While illustrated and described as a repurposed DCI format, DCI format <NUM> may alternatively be a custom format with fields specifically designed to accommodate the signaling according to embodiments of the present disclosure, such as at least one field that is four bits in width for the PUCCH four-bit resource indicator.

A UE <NUM> may recognize whether to look for DCI format <NUM> (<FIG>) or DCI format <NUM> (<FIG>) based on information signaled in a system information message previously, such as the system information message illustrated at action <NUM> in <FIG> discussed above. This may be conveyed as a variable N, where if set to three the UE <NUM> will look in the table for a three-bit-wide PUCCH resource indicator such as the field illustrated in <FIG>. Alternatively, if set to four the UE <NUM> with either look in the table for a MSB field and an LSB field (as illustrated in <FIG>), or a four-bit-wide custom field (with a new, custom DCI format alternative), to obtain a full four-bit-wide PUCCH resource indicator.

In addition to signaling PUCCH resource indicator information via DCI in a PDCCH of a msgB from BS <NUM>, the PUCCH resource indicator may also be conveyed via PDSCH in msgB. Exemplary PDSCH message payload structures are illustrated in <FIG> according to some embodiments of the present disclosure. <FIG> illustrates first a unicast PDSCH message payload structure <NUM> for a targeted UE <NUM>. This includes a MAC subheader, a contention resolution ID, the C-RNTI of the specific UE, a PUCCH resource indication (either dynamic information or hard-coded PUCCH resource indicator that indexes into a look-up table as discussed in the embodiments herein), and a timing advance command. While illustrated as including both contention resolution ID and C-RNTI, in some embodiments either one or the other may be included in the PDSCH message payload structure <NUM> for a unicast message to a UE <NUM>.

<FIG> further illustrates a multicast PDSCH message payload structure <NUM>, which includes messages to multiple UEs <NUM> that share the same RACH occasion. As illustrated, there are two separate payloads <NUM> and <NUM>. This is exemplary, as the multicast PDSCH message payload structure <NUM> may include more payloads than those illustrated according to embodiments of the present disclosure. The two provided are for sake of illustration of examples herein. The payload <NUM> includes information for the first UE, UE1 in the example, for which the PUCCH resource information is being transmitted (via PDSCH of msgB) to the UE1. Thus, it includes the contention resolution ID and/or C-RNTI currently associated with the UE1. Following payload <NUM> is payload <NUM>, including PUCCH resource information for UE2 (which is likewise engaged in a RACH procedure at the time). Thus, it includes contention resolution ID and/or C-RNTI currently associated with UE2, together with the PUCCH resource information for UE2. This continues in like manner for any number of UEs that the BS <NUM> multicasts a msgB to in a RACH procedure.

According to embodiments of the present disclosure, as previously noted the UE <NUM> may receive different PUCCH resource indications via system information, msgB PDCCH, and msgB PDSCH. Each may be partially or wholly different from the others. Thus, embodiments of the present disclosure also describe a tiered approach towards determining which PUCCH resource indication to use to transmit HARQ back to the BS <NUM> after receiving a msgB.

<FIG> illustrates a flow diagram of a wireless communication method <NUM> that implements a tiered approach according to some embodiments of the present disclosure. Aspects of the method <NUM> can be executed by a wireless communication device, such as the UEs <NUM> and/or <NUM> utilizing one or more components, such as the processor <NUM>, the memory <NUM>, the RACH communication and processing module <NUM>, the transceiver <NUM>, the modem <NUM>, the one or more antennas <NUM>, and various combinations thereof. As illustrated, the method <NUM> includes a number of enumerated steps, but embodiments of the method <NUM> may include additional steps before, during, after, and in between the enumerated steps. For example, in some instances one or more aspects of methods <NUM> and/or <NUM>, formats <NUM>, <NUM>, <NUM>, and <NUM>, and/or PDSCH message payload structure from <FIG> may be implemented as part of method <NUM>. Further, in some embodiments, one or more of the enumerated steps may be omitted or performed in a different order.

At block <NUM>, a UE <NUM> receives system information from BS <NUM>. As noted at action <NUM> of <FIG>, a system information message may include various configuration parameters for the subsequent determination of PUCCH resources at the UE <NUM>. For example, the system information message may include default PUCCH resource configuration information including a default resource indicator, as well as bit length size for a resource indicator signaled via PDCCH DCI, and/or identification of RACH message parameter(s) to use when determining a resource indicator. The system information message may also include one or more look-up tables, or updates to look-up tables stored at the UE <NUM>.

At block <NUM>, the UE <NUM> obtains RACH configuration information (e.g., time domain allocations for RACH signaling, RACH preambles as allocation in the frequency domain, etc.) from the system information received at block <NUM>. Further, the UE <NUM> obtains the default PUCCH resource configuration information discussed at block <NUM>.

At block <NUM>, the UE <NUM> transmits a RACH message (e.g., msgA) to the BS <NUM> as part of a RACH procedure, based on the pre-configured resources signaled via the system information discussed above at blocks <NUM> and <NUM>.

At block <NUM>, the UE <NUM> receives a RACH response message (e.g., msgB) from the BS <NUM> in response to the msgA sent at block <NUM>. According to embodiments of the present disclosure, the UE <NUM> attempts to decode the PDCCH and the PDSCH of the msgB to obtain PUCCH resource configuration information for use in HARQ messaging.

The UE <NUM> first attempts to decode the PDCCH of msgB. At decision block <NUM>, if the UE <NUM> is unable to decode the PDCCH of msgB, the method <NUM> proceeds to block <NUM>.

At block <NUM>, the UE <NUM> transmits a HARQ message (e.g., a NACK) to the BS <NUM> based on the default PUCCH resource configuration information obtained at block <NUM>. As an example, the NACK would indicate that the UE <NUM> failed to properly receive the msgB from the BS <NUM>. This provides the BS <NUM> with another opportunity to repeat transmission of msgB to the UE <NUM>, in which case the method <NUM> would begin again at either block <NUM> or <NUM> (depending on whether system information is transmitted again in the interim).

For example, the UE <NUM> may use the default PUCCH resource configuration information when the other sources of PUCCH resource configuration information, such as in a DCI (in PDCCH) or PDSCH, are not available due to decoding failure. Here, since at decision block <NUM> the UE <NUM> was determined to be unable to decode PDCCH, it follows that the UE <NUM> is unable to decode PDSCH (since it is necessary to decode PDCCH in order to decode PDSCH). The default PUCCH resource configuration information may include, for example, a default resource indicator that serves as an index into a look-up table (such as either look-up table <NUM> or <NUM> from <FIG>, respectively). The look-up table may provide a PUCCH resource set (i.e., configuration parameters from a given row) necessary for the PUCCH resource configuration for a HARQ transmission (whether ACK or NACK).

In addition to indexing into the look-up tables based on the default PUCCH resource configuration information obtained via the system information, the UE <NUM> may further configure one or more transmission parameters from their default values in the obtained PUCCH resource set from the look-up table. For example, the initial cyclic shift index may be configured according to one or more parameters the UE <NUM> used when transmitting its msgA at block <NUM>. For example, the parameter from msgA may be a resource index like the preamble sequence index when combined with the cyclic shift identified from the look-up table entry. For example, the initial cyclic shift index may be obtained by equation <NUM>: <MAT>
where the "preamble sequence index" is obtained from the msgA transmission the UE <NUM> made. Thus, most of the PUCCH parameters are obtained from the look-up table, while the cyclic shift may be determined based on a parameter msgA that the UE sends at the start of the RACH procedure. This provides a default choice for the UE <NUM> to use for HARQ messaging when the UE <NUM> is unable to decode msgB PDCCH/PDSCH received at block <NUM>. According to some embodiments of the present disclosure, using configuration information from PDSCH and/or PDCCH is prioritized over using such default configuration information.

Returning to decision block <NUM>, if the UE <NUM> is able to decode the PDCCH of msgB, the method <NUM> instead proceeds to block <NUM>.

At block <NUM>, the UE <NUM> decodes the PDCCH (e.g., including descrambling the PDCCH's CRC using msgB-RNTI) and obtains thereby the DCI in the PDCCH. First, as discussed with respect to previous figures, when obtaining PUCCH resource configuration information from PDCCH the UE <NUM> may further rely upon additional information signaled in the system information messaging received at block <NUM>. The system information message may include a bit length indicator N that identifies what the size (in bits) a resource indicator will be that is included in a msgB's DCI (in PDCCH). For example, the bit length indicator N may identify whether the length of the resource indicator in the DCI is <NUM> bits (such as is used for reduced size look-up tables such as table <NUM> of <FIG>) or <FIG> bits (such as is used for a full-sized look-up table such as table <NUM> of <FIG>). Embodiments of the present disclosure are also applicable to other N values besides these examples.

In further embodiments, the system information may also include an identification for the UE <NUM> to add a resource offset to the configuration information obtained from a look-up table, such as look-up table <NUM>. For example, the system information message may identify a configuration parameter, or a combination of configuration parameters, that will be used in a subsequent RACH procedure for either msgA or msgB involving the UE <NUM>. Some example configuration parameters include the msgA preamble sequence identifier, msgA preamble occasion index, msgA PUSCH occasion, msgB-RNTI, CORESET/search space index for msgB PDCCH, etc., or some combination of parameters as identified by the system information message. The configuration parameters may constitute Q bits of information, where "Q" is a variable for ease of reference herein. Such configuration parameters may be used in combination with a resource indicator to add a resource offset to the PUCCH resources. As a result, a look-up table larger than existing tables (e.g., with more than <NUM> entries) may not be necessary, as the resource offset provides further modification to the existing entries to provide the additional resource scheduling options for the UE <NUM>.

After decoding the PDCCH, the UE <NUM> attempts to decode the PDSCH of msgB using information from the PDCCH. At decision block <NUM>, if the UE <NUM> is unable to decode the PDSCH of msgB, the method <NUM> proceeds to block <NUM>.

At block <NUM>, the UE <NUM> transmits a HARQ message (e.g., a NACK upon failure to decode PDSCH) using the PUCCH configuration information obtained from the PDCCH as discussed at block <NUM>. This provides the BS <NUM> another opportunity to repeat transmission of msgB to the UE <NUM>, in which case the method <NUM> would begin again at either block <NUM> or <NUM> (depending on whether system information is transmitted again in the interim).

For example, transmitting the HARQ message may rely upon the PUCCH configuration information obtained via the DCI resource indicator (and, additionally in some embodiments, the Q-bit information for resource offset where signaled to use such in system information).

Returning to decision block <NUM>, if the UE <NUM> is able to decode the PDSCH of msgB, the method <NUM> instead proceeds to block <NUM> (i.e., instead of transmitting without PUCCH configuration information from the PDSCH of msgB).

At block <NUM>, the UE <NUM> decodes the PDSCH and obtains the PUCCH configuration information transmitted in a PDSCH payload. The PUCCH resource indicator may be transmitted in a unicast payload or a multicast payload, such as those illustrated in <FIG>. The PUCCH resource indication may include a dynamic PUCCH resource configuration, including dynamically selected parameters such as starting location of physical resource blocks (PRB) or PRB offset in the frequency domain, intra-slot frequency hopping, second hop PRB offset, first symbol, number of symbols, initial indices for cyclic shift, number of PRBs, time domain orthogonal cover code (OCC), OCC length, OCC index, inter-slot frequency hopping, additional demodulation reference signal (DMRS) configuration, maximum code rate, number slots, support for π/<NUM> binary phase shift keying (BPSK), and/or support for simultaneous HARQ ACK and CSI, some subset or combination of these, etc. Alternatively, the PUCCH resource indication may be a hard-coded configuration such as in the look-up table examples of <FIG>.

According to some embodiments of the present disclosure, using configuration information from PDSCH is prioritized over using configuration information from PDCCH, which is in turn prioritized over using default configuration information based on the system information.

At block <NUM>, the UE <NUM> transmits a HARQ message (e.g., an ACK or NACK) using the PUCCH configuration information obtained at block <NUM>.

<FIG> illustrates a flow diagram of a wireless communication method <NUM> for the tiered approach according to some embodiments of the present disclosure. Aspects of the method <NUM> can be executed by a wireless communication device, such as the BSs <NUM> and/or <NUM> utilizing one or more components, such as the processor <NUM>, the memory <NUM>, the RACH communication and processing module <NUM>, the transceiver <NUM>, the modem <NUM>, the one or more antennas <NUM>, and various combinations thereof. As illustrated, the method <NUM> includes a number of enumerated steps, but embodiments of the method <NUM> may include additional steps before, after, and in between the enumerated steps. For example, in some instances one or more aspects of methods <NUM> and/or <NUM>, formats <NUM>, <NUM>, <NUM>, and <NUM>, and/or PDSCH message payload structure from <FIG> may be implemented as part of method <NUM>. In some embodiments, one or more of the enumerated steps may be omitted or performed in a different order.

At block <NUM>, the BS <NUM> transmits system information to a UE <NUM> (e.g., broadcast to multiple UEs <NUM>, but described with respect to a single UE <NUM> for sake of simplicity of discussion here). As discussed at block <NUM> of <FIG>, the system configuration may include various types of information. For example, the BS <NUM> may include specific types of information such as default PUCCH configuration information, as well as a value for N, and/or Q, and/or a configuration parameter to use from msgA or msgB, etc., depending upon a determination of what way(s) in which the BS <NUM> will transmit PUCCH configuration information to the UE <NUM>.

At block <NUM>, the BS <NUM> receives a RACH message (e.g., msgA) from the UE <NUM> on pre-configured resources signaled via the system information at block <NUM>.

At block <NUM>, the BS <NUM> transmits a RACH response message (e.g., msgB) to the UE <NUM> in response to the msgA received at block <NUM>. The RACH response message includes PDCCH and PDSCH components. According to embodiments of the present disclosure, the BS <NUM> includes PUCCH resource indicator information in both PUCCH (via DCI) and PDSCH. For example, the BS <NUM> may encode PUCCH resource indicator information into a DCI format (e.g., <FIG>) depending upon the look-up table size signaled by the N value (and also Q where the number of configurations for PUCCH resources is greater than the DCI field size) in the prior system information sent at block <NUM>. This will be used to index into the look-up table (e.g., <FIG>) to obtain PUCCH configuration information. Further, the BS <NUM> may also encode PUCCH configuration information (or just PUCCH resource indicator where the information is hard-coded) into a PDSCH payload, such as that illustrated in <FIG> (whether unicast or multicast).

At block <NUM>, after the UE <NUM> successfully obtained PUCCH configuration information (whether default configuration information, signaled via PDCCH, and/or PDSCH), the BS <NUM> receives a HARQ message on appropriately indicated PUCCH resources, in response to which the BS <NUM> either repeats msgB or continues with the connection process.

<FIG> illustrates a flow diagram of a wireless communication method <NUM> that implements a PDCCH signaling approach using DCI according to some embodiments of the present disclosure. Aspects of the method <NUM> can be executed by a wireless communication device, such as the UEs <NUM> and/or <NUM> utilizing one or more components, such as the processor <NUM>, the memory <NUM>, the RACH communication and processing module <NUM>, the transceiver <NUM>, the modem <NUM>, the one or more antennas <NUM>, and various combinations thereof. As illustrated, the method <NUM> includes a number of enumerated steps, but embodiments of the method <NUM> may include additional steps before, during, after, and in between the enumerated steps. For example, in some instances one or more aspects of methods <NUM> and/or <NUM>, formats <NUM>, <NUM>, <NUM>, and <NUM>, and/or PDSCH message payload structure from <FIG> may be implemented as part of method <NUM>. Further, in some embodiments, one or more of the enumerated steps may be omitted or performed in a different order.

At block <NUM>, the UE <NUM> receives system information from the BS <NUM>, such as discussed above with respect to block <NUM> of <FIG>. In particular, according to the embodiments of <FIG>, the system information includes a bit length size (N value) for a resource indicator signaled via PDCCH DCI, and in some embodiments also a Q value where the number of configurations for PUCCH resources is greater than the DCI field size. The system information may also include one or more look-up tables, or updates thereto.

At block <NUM>, the UE <NUM> stores the bit length indication N from the system information received at block <NUM> for subsequent use in locating a resource indicator in a DCI of a msgB. Where Q is signaled, and/or other information relevant to obtaining the PUCCH configuration information for transmitting a HARQ message, the UE <NUM> may obtain and store those values for use in a RACH procedure as well.

At block <NUM>, the UE <NUM> receives a RACH response message (e.g., msgB) from the BS <NUM> in response to a RACH message (msgA) sent from the UE <NUM> to the BS <NUM>. The RACH response message may include PDCCH and PDSCH components.

At block <NUM>, the UE <NUM> descrambles and decodes the PDCCH starting with the CRC. The UE <NUM> uses msgB-RNTI to perform the descrambling of the CRC.

At decision block <NUM>, if the number of configurations for PUCCH resources is greater than the DCI field size, the method <NUM> proceeds to block <NUM>.

At block <NUM>, the UE <NUM> accesses the resource indicator from the DCI (e.g., from a modified or new DCI format, such as illustrated in <FIG>) that provides a larger resource indicator, e.g. a <NUM>-bit resource indicator.

At block <NUM>, the UE <NUM> accesses the information relating to a Q value (e.g., which message parameter will be used) stored at block <NUM> and determines the Q-bit values. For example, where the system information indicated that a parameter of msgA will provide the Q-bit values, the UE <NUM> will access that information (e.g., msgA preamble sequence identifier, msgA preamble occasion index, msgA PUSCH occasion, etc.). As another example, where msgB is indicated as providing the Q-bit values, the UE <NUM> will access that information (e.g., msgB-RNTI, CORESET/search space index for msgB PDCCH, etc.).

At block <NUM>, the UE <NUM> combines the resource indicator from block <NUM> with the Q-bit values from block <NUM>, which will be converted together from a binary form to a decimal form in order to index into a look-up table with an index value.

Returning now to decision block <NUM>, if the number of configurations for PUCCH resources is not greater than the DCI field size, then the method <NUM> proceeds to decision block <NUM> instead.

At decision block <NUM>, if the system information identified the look-up table to be a reduced look-up table such as table <NUM> from the example of <FIG> (e.g., as indicated by the bit length indicator N), the method <NUM> proceeds to block <NUM>.

At block <NUM>, the UE <NUM> accesses the resource indicator in the PUCCH DCI field. In this example, with the reduced look-up table, the system information the UE <NUM> received at block <NUM> would have signaled a smaller N-value, such as <NUM> bits, for the UE <NUM> to recognize the <NUM>-bit resource indicator in the appropriate field of the DCI upon receipt of the PDCCH for msgB.

Returning to decision block <NUM>, if the system information identified the look-up table to be a larger look-up table such as table <NUM> from the example of <FIG> (e.g., as indicated by the bit length indicator N), the method <NUM> instead proceeds to block <NUM>.

At block <NUM>, the UE <NUM> accesses the MSB of the resource indicator in the appropriate field of a modified DCI (also referred to as a first field herein). This may be, for example, the repurposed/split HARQ Number field at row <NUM> that now repurposed one bit for the MSB field.

At block <NUM>, the UE <NUM> accesses the LSB of the resource indicator in the appropriate field of the modified DCI (also referred to as a second field herein). This may be, for example, the repurposed PUCCH Resource Indicator field at row <NUM> now repurposed as the LSB for PUCCH Resource Indicator field.

At block <NUM>, the UE <NUM> combines the MSB and LSB bits together to form the PUCCH resource indicator that will be used to index into a look-up table. In some embodiments, instead of repurposing an existing DCI format that splits the resource indicator into MSB and LSB fields, the BS <NUM> may signal a new DCI format to the UE <NUM> that has fields specifically purposed for communication according to embodiments of the present disclosure (e.g., one PUCCH resource indicator field with a <NUM>-bit length, etc.).

From any of blocks <NUM>, <NUM>, and <NUM>, the method <NUM> proceeds to block <NUM>.

At block <NUM>, the UE <NUM> translates the resource indicator (determined from blocks <NUM>, <NUM>, or <NUM>) into a decimal format in order to be able to index into the look-up table (e.g., from binary to decimal in some examples). For example, with the resource indicator from either block <NUM> or <NUM>, conversion may take the form of equation <NUM>: <MAT> where bPUCCH,DCI(n) denotes the nth bit of the PUCCH resource indicator in the DCI.

As another example, with the resource indicator from block <NUM> (including the Q-bit information), conversion may take the form of equation <NUM>: <MAT> where bconfig(q) denotes the qth bit of the two step RACH configuration parameters (e.g., from msgA or msgB).

In some examples, bconfig(q) may be a function of the time, frequency, and/or code domain resource index configured for msgA or msgB transmission (or some other parameter as discussed above). An example of bconfig(q) derivation is in equation <NUM>: <MAT> where X may be the msgA preamble sequence ID, msgA preamble/PUSCH occasion index, msgB-RNTI, etc..

After translating the resource indicator to a decimal format, the method <NUM> proceeds to block <NUM>. At block <NUM>, the UE <NUM> accesses the configuration parameters for the PUCCH from the row of the look-up table into which the translated resource indicator indexes. From this information, the method <NUM> may proceed with the UE <NUM> transmitting a HARQ message such as discussed above with respect to block <NUM> above (e.g., where PDSCH is not decoded to obtain the PUCCH configuration information from the PDSCH payload).

<FIG> illustrates a flow diagram of a wireless communication method <NUM> that implements a PDCCH signaling approach using DCI according to some embodiments of the present disclosure. Aspects of the method <NUM> can be executed by a wireless communication device, such as the BSs <NUM> and/or <NUM> utilizing one or more components, such as the processor <NUM>, the memory <NUM>, the RACH communication and processing module <NUM>, the transceiver <NUM>, the modem <NUM>, the one or more antennas <NUM>, and various combinations thereof. As illustrated, the method <NUM> includes a number of enumerated steps, but embodiments of the method <NUM> may include additional steps before, after, and in between the enumerated steps. For example, in some instances one or more aspects of methods <NUM> and/or <NUM>, formats <NUM>, <NUM>, <NUM>, and <NUM>, and/or PDSCH message payload structure from <FIG> may be implemented as part of method <NUM>. In some embodiments, one or more of the enumerated steps may be omitted or performed in a different order.

At block <NUM>, the BS <NUM> transmits system information to one or more UEs <NUM>, such as discussed above with respect to block <NUM>. In particular, according to the embodiments of <FIG>, the system information includes a bit length size (N value) for a resource indicator signaled via PDCCH DCI, and in some embodiments also a Q value where the number of configurations for PUCCH resources is greater than the DCI field size. The system information may also include one or more look-up tables, or updates thereto.

At block <NUM>, the BS <NUM> receives a RACH message (e.g., msgA) from a UE (referring to one UE for sake of illustration), such as discussed above with respect to block <NUM>.

At block <NUM>, the BS <NUM> determines a size of the look-up table (e.g., <NUM> or <NUM> in some examples), following the indication sent at block <NUM> (including the N value identifying which size of look-up table is in use).

At decision block <NUM>, if the look-up table is a reduced-size look-up table, such as table <NUM> of <FIG>, the method <NUM> proceeds to block <NUM>.

At block <NUM>, the BS <NUM> encodes the resource indicator, having a shorter bit length as signaled in the system information at block <NUM>, into a DCI for a PDCCH portion of the msgB transmission.

Returning to decision block <NUM>, if the look-up table is not a reduced-size look-up table (such as table <NUM> of <FIG>), the method <NUM> proceeds to block <NUM>.

At block <NUM>, the BS <NUM> encodes the MSB of the resource indicator, having an overall longer bit length (e.g. four bits), into a first field of the DCI.

At block <NUM>, the BS <NUM> encodes the LSB of the resource indicator (i.e., the remaining bits thereof), into a second field of the DCI. While discussed as separate aspects, in some embodiments, instead of repurposing an existing DCI format that splits the resource indicator into MSB and LSB fields, the BS <NUM> may signal a new DCI format to the UE <NUM> that has fields specifically purposed for communication according to embodiments of the present disclosure (e.g., one PUCCH resource indicator field with a <NUM>-bit length, etc.). In such a case, encoding from blocks <NUM> and <NUM> would involve encoding to one overall field.

From either blocks <NUM> or <NUM>, the method <NUM> proceeds to block <NUM>. At block <NUM>, the BS <NUM> transmits the RACH response message (msgB) with the DCI including encoded resource indicator in the PDCCH to the UE <NUM>. The UE <NUM> will proceed to use this information for determining PUCCH resources to use in sending the HARQ message, as discussed above.

<FIG> illustrates a flow diagram of a wireless communication method <NUM> that implements a PDCCH signaling approach using PDSCH payload according to some embodiments of the present disclosure. Aspects of the method <NUM> can be executed by a wireless communication device, such as the UEs <NUM> and/or <NUM> utilizing one or more components, such as the processor <NUM>, the memory <NUM>, the RACH communication and processing module <NUM>, the transceiver <NUM>, the modem <NUM>, the one or more antennas <NUM>, and various combinations thereof. As illustrated, the method <NUM> includes a number of enumerated steps, but embodiments of the method <NUM> may include additional steps before, during, after, and in between the enumerated steps. For example, in some instances one or more aspects of methods <NUM> and/or <NUM>, formats <NUM>, <NUM>, <NUM>, and <NUM>, and/or PDSCH message payload structure from <FIG> may be implemented as part of method <NUM>. Further, in some embodiments, one or more of the enumerated steps may be omitted or performed in a different order.

At block <NUM>, the UE <NUM> receives a RACH response message (e.g., msgB) from the BS <NUM> in response to the UE <NUM> previously sending a RACH message (e.g., msgA) to the BS <NUM>.

At block <NUM>, upon successfully decoding the PDCCH, the UE <NUM> decodes the PDSCH using information from the PDCCH.

At block <NUM>, the UE <NUM> accesses the resource indicator from the decoded PDSCH portion that includes the UE's identifier. For example, referring to <FIG>'s PDSCH message payload structure (either unicast or multicast), the UE <NUM> accesses the payload structure and locates the PUCCH resource indication and any other parameters for the PUCCH associated with the UE's payload portion. This may be identified, for example, by the UE <NUM>'s contention resolution ID and/or C-RNTI included in the payload as well. From this information, the method <NUM> may proceed with the UE <NUM> transmitting a HARQ message such as discussed above with respect to block <NUM> above (e.g., where PDSCH is decoded to obtain the PUCCH configuration information from the PDSCH payload).

<FIG> illustrates a flow diagram of a wireless communication method <NUM> that implements a PDCCH signaling approach using PDSCH payload according to some embodiments of the present disclosure. Aspects of the method <NUM> can be executed by a wireless communication device, such as the BSs <NUM> and/or <NUM> utilizing one or more components, such as the processor <NUM>, the memory <NUM>, the RACH communication and processing module <NUM>, the transceiver <NUM>, the modem <NUM>, the one or more antennas <NUM>, and various combinations thereof. As illustrated, the method <NUM> includes a number of enumerated steps, but embodiments of the method <NUM> may include additional steps before, after, and in between the enumerated steps. For example, in some instances one or more aspects of methods <NUM> and/or <NUM>, formats <NUM>, <NUM>, <NUM>, and <NUM>, and/or PDSCH message payload structure from <FIG> may be implemented as part of method <NUM>. In some embodiments, one or more of the enumerated steps may be omitted or performed in a different order.

At block <NUM>, the BS <NUM> receives a RACH message (e.g., msgA) from a UE, such as discussed above with respect to block <NUM>.

At block <NUM>, the BS <NUM> encodes the PUCCH configuration information (e.g., either the dynamically configured by RRC or hard coded with look-up table) into a PDSCH payload, such as illustrated in <FIG> (for either unicast or multicast).

At decision block <NUM>, if there are other UEs which are part of the same RACH occasion, the method <NUM> may return to block <NUM> in order to encode PUCCH configuration information into a multicast payload in PDSCH.

If instead at decision block <NUM> there are no further UEs part of the same RACH occasion which have transmitted a msgA to the BS <NUM>, the method <NUM> proceeds to block <NUM>.

At block <NUM>, the BS <NUM> transmits a RACH response message (msgB) to the UE(s) that had sent a msgA with respect to block <NUM>. The msgB includes a PDSCH that has the resource indicator/configuration information encoded into the PDSCH payload, which the UE will attempt to decode in order to use for a HARQ message.

Claim 1:
A method of wireless communication comprising:
receiving, by a user equipment, UE (<NUM>), from a base station, BS (<NUM>), a random access channel, RACH, response message as part of a two-step RACH procedure;
decoding, by the UE, a physical downlink control channel, PDCCH, of the RACH response message to obtain a resource indicator based on a downlink control information, DCI, of the PDCCH;
decoding, by the UE, a physical downlink shared channel, PDSCH, of the RACH response message to obtain a resource indicator from the PDSCH;
determining, by the UE, physical uplink control channel, PUCCH, resources to use for a hybrid automatic repeat request, HARQ, procedure from accessing a look-up table based on the resource indicator from the PDCCH, if PDCCH is successfully decoded and PDSCH is not successfully decoded, or
determining, by the UE, PUCCH resources to use for a HARQ procedure based on the resource indicator from the PDSCH, if PDCCH and PDSCH are successfully decoded; and
transmitting, by the UE to the BS, a HARQ message using the PUCCH resources based on whether receiving the RACH response message was successful or not.