Patent Description:
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).

In a wireless system, BSs may broadcast synchronization signals such as primary synchronization signal (PSS), secondary synchronization signal (SSS), and extended synchronization signal (ESS), beam reference signal (BRS) and system information in a plurality of directional beams. In addition, the BSs may transmit other reference signals, such as channel state information reference signal (CSI-RS), over the beams to enable UEs to measure channels between the BS and corresponding UEs. A UE may perform initial cell acquisition by listening to the broadcast signals and perform signal measurements based on the synchronization signals, the BRS and/or other signals. The UE may determine receive signal strengths based on the received signals and select a cell and a beam within the selected cell for performing an access procedure.

To perform an access procedure, a UE may initiate a random-access channel (RACH) procedure by sending a random-access preamble using the same subarray and beam direction as the selected beam and monitor for a random-access response (RAR) in a RAR window. Traditionally, a <NUM>-step RACH procedure is used to configure the connection between the UE and the BS, for example, as defined in the New Radio (NR) Release-<NUM> and/or earlier versions of the NR Release. In NR Release-<NUM>, a <NUM>-step RACH procedure is defined, in which a MsgA transmitted from the UE to the BS combines the Msg1 and Msg3 in the <NUM>-step RACH procedure, and a MsgB transmitted from the BS to the UE combined the Msg2 and Msg4 in the <NUM>-step RACH procedure. With only <NUM> message exchanges instead of <NUM>, the <NUM>-step RACH procedure may be more advantageous in latency reduction compared to the traditional <NUM>-step RACH procedure. As a UE designed under NR Release-<NUM> is expected to support both the <NUM>-step RACH and the <NUM>-step RACH, existing specification in the NR Release-<NUM> adopts some existing resource allocation tables that were designed for the <NUM>-step RACH to define transmission occasions for MsgA in the <NUM>-step RACH. In this case, the transmission occasion allocated for the <NUM>-step RACH may collide with the transmission occasion allocated for the <NUM>-step RACH.

Therefore, there is a need to manage the transmission occasions for a UE that is compatible with both the <NUM>-step RACH and the <NUM>-step RACH in wireless communication systems. Documents <NPL>) and <NPL>), both provide background to the validity of PUSCH occasions upon collision with RACH occasions.

The following summarizes some aspects of the present disclosure to provide a basic understanding of the discussed technology. This summary is not an extensive overview of all contemplated features of the disclosure and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in summary form as a prelude to the more detailed description that is presented later.

In accordance with the present invention, a method, an apparatus and a storage medium, as set forth in the independent claims, respectively, are provided. Additional embodiments of the invention are described in the dependent claims.

Provided is a method of wireless communication, comprising:.

Further provided is a corresponding user equipment apparatus and storage medium.

This disclosure relates generally to wireless communications systems, also referred to as wireless communications networks. In various aspects, 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 a 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.

In addition, such an apparatus may be implemented, or such a method may be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein.

In a wireless system, when a UE wants to access the network, the UE may attempt to try to attach or synchronize with the BS. In order to be synchronized with the network, a RACH procedure is used. For example, traditionally, a <NUM>-step RACH procedure is used for UE to establish a synchronized connection with BS. Specifically, in system information block (SIB2), BS such as the next generation node B (gNB) periodically broadcasts several parameters such as root sequence ID, RACH configuration index, power offset, and initial power. In a contention-based RACH procedure, the UE randomly selects a preamble out of the <NUM> orthogonal zadoff-chu (ZC) sequences generated by root sequence cyclic shift, which is transmitted as Msg <NUM> on the random access subframe in time and resource block (RB) in frequency implicitly defining the RA-radio network temporary identifier (RA-RNTI). The gNB responds with Msg <NUM> random access response (RAR) containing a temporary cell-RNTI (C-RNTI), timing advance (TA) and uplink resource grant upon Msg <NUM> success. In Msg <NUM>, the UE transmits a radio resource control (RRC) connection request including a randomly chosen initial device identity after decoding the RB assignment from Msg <NUM>. Multiple UEs can select the same preamble, RA-RNTI in Msg <NUM> and also the corresponding C-RNTI in Msg <NUM> and transmit their own Msg <NUM> on the uplink resources which is detected as a collision by gNB. In Msg <NUM>, the gNB sends RRC connection setup with a permanent C-RNTI and an echo of the initial identity transmitted in Msg <NUM> by the device. RACH procedure is considered as a success if the identities are matched else the device retries the procedure after a back-off interval. The successful UE is ready to transmit uplink data.

To lower the access delay of the <NUM>-step RACH access procedure, a <NUM>-step RACH procedure can be used, in which the UE combines Msg1 and Msg3 into one initial message, referred to as "MsgA," and the BS in turn responds with a combined message of the traditional Msg2 and Msg4, referred to as "MsgB. " In accordance with aspects of the present disclosure, the <NUM>-step RACH procedure, as further described in relation to <FIG>, transmits a random-access preamble of MsgA over a RACH occasion, and a payload of MsgA over a PUSCH occasion. The RACH occasion and/or the PUSCH occasion for the <NUM>-step RACH is defined by the network and transmitted to the UE via remaining system information (RMSI), other system information (SI) or radio resource control (RRC) messages.

As a UE designed under NR Release-<NUM> is expected to support both the <NUM>-step RACH and the <NUM>-step RACH, existing specification in the NR Release-<NUM> adopts some existing resource allocation tables that were designed for the <NUM>-step RACH to define transmission occasions for MsgA in the <NUM>-step RACH. In this case, the transmission occasion allocated for the <NUM>-step RACH may collide with the transmission occasion allocated for the <NUM>-step RACH.

In view of the need to manage the transmission occasions, embodiments described herein, as further described in relation to <FIG>, provide ways to validate a PUSCH occasion defined for <NUM>-step RACH in case of collisions. According to the invention, the UE determines whether a collision occurs between the PUSCH occasion for the <NUM>-step RACH and any RACH occasion assigned for either <NUM>-step RACH or <NUM>-step RACH after receiving the RACH configuration or updates from the network. The UE then excludes the PUSCH occasion from the resource pool for <NUM>-step RACH when a collision occurs.

<FIG> illustrates a wireless communication network <NUM> according to some aspects 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" can 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).

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.

The BSs <NUM> can 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 can 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 can 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 can 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 aspects, 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 can 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 some aspects, the network <NUM> may be an NR network deployed over a licensed spectrum. The BSs <NUM> can 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> can 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 some aspects, 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> can perform a random-access procedure to establish a connection with the BS <NUM>. In some examples, the random-access procedure may be a four-step random access procedure. For example, 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 can be referred to as message <NUM> (MSG1), message <NUM> (MSG2), message <NUM> (MSG3), and message <NUM> (MSG4), respectively. In some examples, 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.

After establishing a connection, the UE <NUM> and the BS <NUM> can enter a normal operation stage, 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 instances, the BS <NUM> may communicate data with the UE <NUM> using hybrid automatic request (HARQ) to improve communication reliability. The BS <NUM> may schedule a UE <NUM> for a PDSCH communication by transmitting a DL grant in a PDCCH. The BS <NUM> may transmit a DL data packet to the UE <NUM> according to the schedule in the PDSCH. The DL data packet may be transmitted in the form of a transport block (TB). If the UE <NUM> receives the DL data packet successfully, the UE <NUM> may transmit a HARQ ACK to the BS <NUM>. Conversely, if the UE <NUM> fails to receive the DL transmission successfully, the UE <NUM> may transmit a HARQ NACK to the BS <NUM>. Upon receiving a HARQ NACK from the UE <NUM>, the BS <NUM> may retransmit the DL data packet to the UE <NUM>. The retransmission may include the same coded version of DL data as the initial transmission. Alternatively, the retransmission may include a different coded version of the DL data than the initial transmission. The UE <NUM> may apply soft-combining to combine the encoded data received from the initial transmission and the retransmission for decoding. The BS <NUM> and the UE <NUM> may also apply HARQ for UL communications using substantially similar mechanisms as the DL HARQ.

In some aspects, the network <NUM> may operate over a system BW or a component carrier BW. The network <NUM> may partition the system BW into multiple BWPs (e.g., portions). A BS <NUM> may dynamically assign a UE <NUM> to operate over a certain BWP (e.g., a certain portion of the system BW). The assigned BWP may be referred to as the active BWP. The UE <NUM> may monitor the active BWP for signaling information from the BS <NUM>. The BS <NUM> may schedule the UE <NUM> for UL or DL communications in the active BWP. In some aspects, a BS <NUM> may assign a pair of BWPs within the component carrier to a UE <NUM> for UL and DL communications. For example, the BWP pair may include one BWP for UL communications and one BWP for DL communications. The BS <NUM> may additionally configure the UE <NUM> with one or more CORESETs in a BWP. A CORESET may include a set of frequency resources spanning a number of symbols in time. The BS <NUM> may configure the UE <NUM> with one or more search spaces for PDCCH monitoring based on the CORESETS. The UE <NUM> may perform blind decoding in the search spaces to search for DL control information (e.g., UL and/or DL scheduling grants) from the BS. In an example, the BS <NUM> may configure the UE <NUM> with the BWPs, the CORESETS, and/or the PDCCH search spaces via RRC configurations.

In some aspects, 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 employ a LBT procedure to acquire channel occupancy time (COT) in the share medium for communications. A COT may be non-continuous 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). The BS <NUM> or the UE <NUM> may perform an LBT in the frequency band prior to transmitting in the frequency band. The LBT can be based on energy detection or signal detection. For energy detection, the BS <NUM> or the UE <NUM> may determine that the channel is busy or occupied when a signal energy measured from the channel is greater than a certain signal energy threshold. For signal detection, the BS <NUM> or the UE <NUM> may determine that the channel is busy or occupied when a certain reservation signal (e.g., a preamble signal sequence) is detected in the channel.

Further, the BS <NUM> may configure UEs <NUM> with narrowband operation capabilities (e.g., with transmission and/or reception limited to a BW of <NUM> or less) to perform BWP hopping for channel monitoring and communications. Mechanisms for performing BWP hopping are described in greater detail herein.

<FIG> illustrates a random-access scheme in a wireless communication network <NUM> according to aspects of the present disclosure. The network <NUM> corresponds to a portion of the network <NUM>. <FIG> illustrates one BS <NUM> and one UE <NUM> for purposes of simplicity of discussion, though it will be recognized that aspects of the present disclosure may scale to many more UEs <NUM> and/or BSs <NUM>. The BS <NUM> corresponds to one of the BSs <NUM>. The UE <NUM> corresponds to one of the UEs <NUM>. The UE <NUM> and BS <NUM> may communicate with each other at any suitable frequencies.

In <FIG>, BS <NUM> sends synchronization signals, BRSs, and system information over a plurality of directional beams <NUM> in a plurality of directions as shown by the dashed oval <NUM>. To access the network <NUM>, UE <NUM> listens to the synchronization signals and/or the BRSs and selects a beam for performing a random-access procedure. For example, UE <NUM> can receive the beams 211a, 211b, and 211c and selects the beam 211b for the random access. The UE <NUM> sends a random-access preamble over a beam <NUM> in the beam direction of the beam 211b and monitors for a RAR from BS <NUM>. Upon detecting the random-access preamble, BS <NUM> sends a RAR over the beam 211b in the same beam direction at which the random-access preamble is received. The BS <NUM> sends the RAR over the beam 211b using an entire subframe. This can be resource inefficient when a large bandwidth is available. In addition, by the time BS <NUM> sends the RAR, UE <NUM> may have moved to a different location away from the beam 211b as shown by the dashed arrows. Thus, UE <NUM> may fail to receive the RAR from the beam 211b. An additional cause of RAR failure may be due to beam correspondence. Although UE <NUM> may retry for another random-access attempt after waiting for a period of time (e.g., a backoff period), the retry adds additional latency. Thus, sending a single random-access preamble over a single beam direction per random access attempt may not be robust enough to successfully complete the RACH procedure.

<FIG> illustrates a transmission scenario of a <NUM>-step RACH scheme between a UE <NUM> and a BS <NUM> that may be implemented in the wireless communication network shown in <FIG>, according to some aspects of the present disclosure.

Diagram <NUM> in <FIG> shows a <NUM>-step RACH procedure that lowers the access delay in the control plane as compared to the traditional <NUM>-step RACH. The system information block (e.g., SIB2) and RRC signaling is transmitted to UE <NUM> from BS <NUM> at <NUM>, and UE <NUM> decodes the system information and RRC signaling, which may contain resource allocation information relating to the RACH occasions and/or PUSCH occasions for the <NUM>-step RACH or <NUM>-step RACH at <NUM>. UE <NUM> then transmits a Msg A that includes the <NUM>-step RACH Msg <NUM> and Msg <NUM>, e.g., including a random-access preamble 340a transmitted over a RACH occasion followed by the payload 340b for the random-access message (connection request, device ID, buffer status report, etc.) transmitted over a PUSCH occasion at <NUM>. UE <NUM> then monitors for a Msg B from BS <NUM> at <NUM> while BS <NUM> processes and decodes Msg A at <NUM>. The MsgB is transmitted from BS <NUM>, which corresponds to the Msg <NUM> and Msg <NUM> of <NUM>-step RACH, e.g., the RAR, timing advance and finally the connection complete with RRC response message at <NUM>. Thus, the <NUM>-step RACH is able to set up a connection between UE <NUM> and BS <NUM> for UE <NUM> to start transmitting uplink data with a reduced access delay, e.g., <NUM> message exchange vs. traditional <NUM> message exchange.

As shown at <NUM>, the preamble 340a of the MsgA is transmitted over a RACH occasion, and the payload 340b of the MsgA is transmitted over a PUSCH occasion. The network defines the RACH occasions and PUSCH occasions for the <NUM>-step RACH, and transmits information relating to the occasions to the UE via RMSI, other system information, or RRC messages. When the UE <NUM> is compatible with both <NUM>-step RACH and <NUM>-step RACH, the UE <NUM> may receive occasion allocation information relating to the <NUM>-step RACH and the <NUM>-step RACH. Existing systems may use the same PRACH configuration table that was defined for the <NUM>-step RACH to assign RACH occasions for the <NUM>-step RACH. As there is a limited number of rows in the table, the RACH occasion for a <NUM>-step RACH may collide in time-frequency with that of a <NUM>-step RACH even when they were intended to be separate ones (i.e., without preamble partitioning). The collision may result in serious logic confusions, e.g., a gNB may have to respond with a msg2 in <NUM>-step RACH and a msgB in a <NUM>-step RACH for a detected preamble.

Existing agreement in 3GPP include certain rules for a UE to invalidate a <NUM>-step RACH occasion following the same rules that are used for the invalidation of <NUM>-step RACH occasions when a collision occurs, which can be found be section <NUM> of TS <NUM>. However, no existing agreement has been reached to manage the situation when a PUSCH occasion defined for the <NUM>-step RACH collides with other occasions, e.g., the RACH occasion defined for the <NUM>-step RACH or the RACH occasion defined for the <NUM>-step RACH.

In view of the need to manage the transmission occasions, embodiments described herein, as further described in relation to <FIG>, provide ways to validate a PUSCH occasion defined for <NUM>-step RACH in case of collisions. Such collision may not always happen (i.e., not expected by a UE) with careful PUSCH occasion allocation. However, a sophisticated/complete design of PUSCH occasion allocation may not always be realized due to the tight schedule of 3GPP. In some implementations, a PUSCH occasion may need to be validated together, or separately, with the corresponding RACH occasion. For example, the UE may determine whether a collision occurs between the PUSCH occasion for the <NUM>-step RACH and any RACH occasion assigned for either <NUM>-step RACH or <NUM>-step RACH after receiving the RACH configuration or updates from the network. The UE may then exclude the PUSCH occasion from the resource pool for <NUM>-step RACH when a collision occurs.

<FIG> is a block diagram of an exemplary UE <NUM> according to some aspects of the present disclosure. The UE <NUM> may be a UE <NUM> discussed above in <FIG> or UE <NUM> shown in other figures, for example. As shown, the UE <NUM> may include a processor <NUM>, a memory <NUM>, a BWP hopping module <NUM>, a communication interface <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 aspect, 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 aspects of the present disclosure, for example, aspects of FIGS. 3A-3C and 6A-<NUM>. Instructions <NUM> may also be referred to as program code. The program code may be for causing a 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 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 module <NUM> may communicate with the communication interface <NUM> to receive from or transmit messages to another device. Each of the RACH module <NUM> and the communication interface <NUM> may be implemented via hardware, software, or combinations thereof. For example, each of the RACH module <NUM> and the communication interface <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 module <NUM> and the communication interface <NUM> can be integrated within the modem subsystem <NUM>. For example, the RACH module <NUM> and the communication interface <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>. In some examples, a UE may include one of the RACH module <NUM> and the communication interface <NUM>. In other examples, a UE may include both the RACH module <NUM> and the communication interface <NUM>.

The RACH module <NUM> and the communication interface <NUM> may be used for various aspects of the present disclosure, for example, aspects of <FIG> and <FIG>. The RACH module <NUM> is configured to receive from a BS (e.g., <NUM>) system information that includes definitions of RACH occasions and PUSCH occasions for initiating a RACH procedure. The RACH module <NUM> is further configured to validate or invalidate the RACH occasions and/or the PUSCH occasions before transmitting MsgA including a random-access preamble and a payload containing a connection request to the BS.

The communication interface <NUM> is configured to coordinate with the RACH module <NUM> to receive system information, MsgB and/or other DL scheduling grants from the BS, and/or communicate with the BS according to the UL and/or DL scheduling grants. The communication interface <NUM> is further configured to transmit MsgA, and/or other UL data to the BS.

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>, the RACH module <NUM>, and/or the communication interface <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., PUCCH, PUSCH, channel reports, ACK/NACKs) 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., DL data blocks, PDSCH, PUSCH, BWP hopping configurations and/or instructions) to the RACH module <NUM> and/or communication interface <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 aspect, the UE <NUM> can include multiple transceivers <NUM> implementing different RATs (e.g., NR and LTE). In an aspect, the UE <NUM> can include a single transceiver <NUM> implementing multiple RATs (e.g., NR and LTE). In an aspect, 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 some aspects of the present disclosure. The BS <NUM> may be a BS <NUM> as discussed above in <FIG> and BS <NUM> described in other figures, for example. As shown, the BS <NUM> may include a processor <NUM>, a memory <NUM>, a RACH module <NUM>, a communication interface <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 memory <NUM> may include a cache memory (e.g., a cache memory of the processor <NUM>), RAM, MRAM, ROM, PROM, EPROM, EEPROM, flash memory, a solid-state memory device, one or more hard disk drives, memristor-based arrays, other forms of volatile and non-volatile memory, or a combination of different types of memory. In some aspects, the memory <NUM> may include a non-transitory computer-readable medium. 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> and <NUM>-<NUM>, and <NUM>.

The RACH module <NUM> and the communication interface <NUM> may be used for various aspects of the present disclosure, for example, aspects of <FIG> and <FIG>. The RACH module <NUM> is configured to broadcast system information that includes definitions of RACH occasions and PUSCH occasions for initiating a random-access channel procedure. The RACH module <NUM> is further configured to receive MsgA including a random-access preamble received over the RACH occasion and a payload containing a connection request received over the PUSCH occasion.

The communication interface <NUM> is configured to coordinate with the RACH module <NUM> to broadcast system information, or to transmit MsgB to the UE. The communication interface <NUM> is further configured to receive MsgA or other UL data from the UE.

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., BWP hoping configurations and instructions, PDCCH, PDSCH) from the modem subsystem <NUM> (on outbound transmissions) or of transmissions originating from another source such as a UE <NUM> and <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 aspects 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., channel reports, PUSCH, PUCCH, HARQ ACK/NACKs) to the RACH module <NUM> and/or communication interface <NUM> for processing. The antennas <NUM> may include multiple antennas of similar or different designs in order to sustain multiple transmission links.

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

<FIG> illustrates a diagram showing a collision between the <NUM>-step RACH PUSCH occasion and the <NUM>-step or <NUM>-step RACH occasion, according to some aspects of the present disclosure. For example, a collision in time and frequency between the PUSCH occasion <NUM> for the <NUM>-step RACH and the RACH occasion <NUM> for the <NUM>-step RACH or the RACH occasion <NUM> for the <NUM>-step RACH happens when the two occasions <NUM> and <NUM>, or <NUM> and <NUM> overlap over at least one OFDM symbol (in time) × one sub-carrier spacing (in frequency). That is, as illustrated by the area labeled as "A," when the overlapping area "A" has a non-zero area.

In some embodiments, when the collision happens, for <NUM>-step RACH, PUSCH occasion <NUM> is first validated with the SSB and the downlink pattern in TDD, e.g., fowling the procedure as described in Section <NUM> of TS38. A PUSCH occasion <NUM> for <NUM>-step RACH is then validated with the <NUM>-step RACH occasion <NUM> and the <NUM>-step RACH occasion <NUM>. The PUSCH occasion <NUM> is invalid if it collides with either RACH occasion <NUM> or <NUM>. The invalid PUSCH occasion is not considered in any association between the SSB and <NUM>-step RACH occasion/PUSCH occasion pairs, e.g., being excluded from the RACH resource pool.

In some embodiments, for <NUM>-step RACH, PUSCH occasion <NUM> may only be validated with the SSB and the downlink pattern in TDD, e.g., following the procedure as described in Section <NUM> of TS38. In this case, the UE replies on a careful design of occasion allocation and does not expect the PUSCH occasion <NUM> for <NUM>-step RACH to collide with the RACH occasions <NUM> or <NUM> for the <NUM>-step RACH or <NUM>-step RACH.

In some embodiments, the PUSCH occasion <NUM> is considered to collide with the RACH occasions <NUM> or <NUM> when the overlapping area A is greater than a threshold portion of area B (the total area of the RACH occasions <NUM> or <NUM>), e.g., <NUM>%, <NUM>%, etc. The invention is based on this concept. The threshold ratio may be defined by the network in guiding the validation procedure of the UE and may be transmitted to the UE via system information or RRC messages.

<FIG> illustrates a diagram showing aspects of managing transmission occasions for the <NUM>-step RACH PUSCH occasion through the PUSCH occasion <NUM>-<NUM> to RACH occasion association <NUM>-<NUM>, according to some aspects of the present disclosure. For <NUM>-step RACH occasion/PUSCH occasion association with SSB, the UE may independently conduct SSB association with valid <NUM>-step RACH occasions, and SSB association with valid PUSCH occasions. For example, the UE may associate SSB <NUM> with RACH occasions <NUM>-<NUM>, and independently associate SSB <NUM> with PUSCH occasions <NUM>-<NUM>, if the occasions <NUM>-<NUM> and <NUM>-<NUM> are valid with respect to the collision scenario described in relation to <FIG>. Then the RACH occasions and PUSCH occasions associated with the same SSB(s) are further associated using the association rule defined by network. For example, here, as RACH occasions <NUM>-<NUM> and PUSCH occasions <NUM>-<NUM> are all associated with SSB <NUM>. RACH occasion <NUM>, <NUM>, <NUM> may be associated PUSCH occasion <NUM>, <NUM>, <NUM>, respectively, as pairs.

If no association between the PUSCH occasion and RACH occasion, using the association rule defined by network, can be established for a valid RACH occasion or a valid PUSCH occasion, the PUSCH occasion or the RACH occasion is excluded from the <NUM>-step RACH resource pool. For example, as illustrated by the solid line between RACH occasion <NUM> and PUSCH occasion <NUM>, when both RACH occasion <NUM> and PUSCH occasion <NUM> are valid (e.g., not colliding with other RACH or PUSCH occasion), and are both associated with the same SSB <NUM>, RACH occasion <NUM> and PUSCH occasion <NUM> are then considered valid occasion pair for MsgA transmission. For another example, if either a PUSCH occasion (e.g., <NUM>) or a RACH occasion (e.g., <NUM>) is invalid, e.g., invalidated with SSB <NUM> or the downlink pattern in TDD, or colliding with another RACH occasion, as shown by the dashed line between occasions <NUM> and <NUM>, <NUM> and <NUM>, respectively, the invalid PUSCH occasion <NUM> or the invalid RACH occasion <NUM> are to be excluded from the RACH resource pool, and thus will not be used to form the transmission occasion pair with RACH occasion <NUM>, or PUSCH occasion <NUM>, respectively.

In an alternative embodiment, instead of first determining whether a PUSCH or RACH occasion is valid, the UE may first associate the <NUM>-step RACH occasion and PUSCH Occasion using the association rule from the network, e.g., forming the occasion pairs <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>. The UE may then run validation on the RACH occasions <NUM>-<NUM> and PUSCH occasions <NUM>-<NUM>, e.g., following similar procedure described in relation to <FIG>. If either a RACH occasion (e.g., <NUM>) or a PUSCH occasion (e.g., <NUM>) is invalid, the occasion pair (e.g., <NUM>-<NUM>, <NUM>-<NUM>) for <NUM>-step RACH is invalid and will be excluded from RACH resource pool.

In this way, each SSB (e.g., <NUM>) is associated with the set of valid occasion pairs, e.g., the pair of RACH occasion <NUM> and PUSCH occasion <NUM>.

<FIG> provides a diagram illustrating a scenario where a PUSCH occasion for <NUM>-step RACH is considered valid if the PUSCH occasion only collides with a RACH occasion that is associated to a different SSB, according to some embodiments of the present technology. For example, even if the PUSCH occasion <NUM> for <NUM>-step RACH is determined to collide with the RACH occasion <NUM> or <NUM> shown in <FIG>, but if PUSCH occasion <NUM> is associated with SSB <NUM> that is different from the SSB <NUM> that is associated with the colliding RACH occasion <NUM> or <NUM>, the PUSCH occasion <NUM> is still considered valid for MsgA transmission.

<FIG> illustrates a logic flow performed by the UE corresponding to the validation procedure of PUSCH occasion <NUM> for <NUM>-step RACH described in relation to <FIG>, according to some aspects of the present disclosure. Steps of the method <NUM> can be executed by a computing device (e.g., a processor, processing circuit, and/or other suitable component) of a wireless communication device or other suitable means for performing the steps. For example, a wireless communication device, such as the UE <NUM>, UE <NUM> or UE <NUM>, may utilize one or more components, such as the processor <NUM>, the memory <NUM>, the RACH module <NUM>, the communication interface <NUM>, the transceiver <NUM>, the modem <NUM>, and the one or more antennas <NUM>, to execute the steps of method <NUM>. As illustrated, the method <NUM> includes a number of enumerated steps, but aspects of the method <NUM> include additional steps before, after, and in between the enumerated steps. In some aspects, one or more of the enumerated steps may be omitted or performed in a different order.

At step <NUM>, the UE may receive configuration of a first RACH occasion or a first PUSCH occasion for a first RACH procedure. For example, the UE may receive RACH/PUSCH occasion for the <NUM>-step RACH, e.g., via RMSI, other system information or RRC messages from the BS.

At step <NUM>, the UE may receive configuration of a second RACH occasion for a second RACH procedure. For example, the UE may also receive RACH/PUSCH occasion for the <NUM>-step RACH.

At step <NUM>, the UE may validate the PUSCH occasion with SSB and downlink pattern in TDD. For example, the UE may validate the PUSCH occasion for <NUM>-step RACH with SSB or downlink pattern in TDD according to Section <NUM> of TS38.

At step <NUM>, the UE may optionally finish the PUSCH occasion validation as the UE does not expect the PUSCH occasion for <NUM>-step RACH to collide with any RACH occasion.

Or alternatively, at step <NUM>, the UE may determine whether the first PUSCH occasion (e.g., <NUM>) collide with the first RACH occasion (e.g., <NUM>) or the second RACH occasion (e.g., <NUM>). For example, the UE may determine whether the first PUSCH occasion overlaps with the first or second RACH occasion at all, and/or whether the overlapping area is greater than a threshold portion of the first or second RACH occasion, which is reflected in the invention.

At step <NUM>, if a collision is found, method <NUM> proceeds to step <NUM> to determine that the first PUSCH occasion is invalid, and then the first PUSCH occasion is excluded from the RACH resource pool at step <NUM>. At step <NUM>, the UE may transmit MsgA to the BS using available PUSCH occasions and RACH occasions selected from the updated RACH resource pool.

At step <NUM>, if no collision is found, method <NUM> proceeds to step <NUM> to transmit to the BS MsgA using the first PUSCH occasion (for the payload) and the first RACH occasion (for the preamble).

At step <NUM>, continued from step <NUM> in <FIG>, the UE determines the first PUSCH occasion and the first RACH occasion is valid. For example, the UE may follow method <NUM> in <FIG> to determine that the PUSCH occasion for <NUM>-step RACH is valid.

At step <NUM>, the UE may conduct an association of a first SSB with the first PUSCH occasion. For example, the UE associates SSB <NUM> with valid PUSCH occasions <NUM> and <NUM> in <FIG>.

At step <NUM>, the UE may conduct an association of a second SSB with the first RACH occasion. For example, the UE associates SSB <NUM> (or other SSBs) with valid RACH occasions <NUM> and <NUM> in <FIG>.

At step <NUM>, the UE determine whether the first SSB and the second SSB are the same. In this example shown in <FIG>, the same SSB <NUM> is used.

At step <NUM>, when the SSBs are the same, method <NUM> proceeds to step <NUM>, at which the first PUSCH occasion is associated with the first RACH occasion, e.g., according to association rules. For example, PUSCH occasion <NUM> and RACH occasion <NUM>, both of which are valid and are associated with the same SSB, are associated as a PUSCH-RACH occasion pair according to the association rule, as shown in <FIG>. Method <NUM> then proceeds to step <NUM> in <FIG>.

At step <NUM>, if the valid PUSCH occasion and valid RACH occasion do not associate with the same SSB-in other words, the valid PUSCH occasions and valid RACH occasions cannot form a pair as they do not associate with the same SSB. The UE may exclude the first PUSCH occasion or the first RACH occasion from the RACH resource pool at step <NUM>. Method <NUM> then proceeds to step <NUM> in <FIG>.

<FIG> illustrates an alternative logic flow performed by the UE corresponding to the validation procedure of PUSCH occasion <NUM> for <NUM>-step RACH described in relation to <FIG>, according to some aspects of the present disclosure. Steps of the method <NUM> can be executed by a computing device (e.g., a processor, processing circuit, and/or other suitable component) of a wireless communication device or other suitable means for performing the steps. For example, a wireless communication device, such as the UE <NUM>, UE <NUM> or UE <NUM>, may utilize one or more components, such as the processor <NUM>, the memory <NUM>, the RACH module <NUM>, the communication interface <NUM>, the transceiver <NUM>, the modem <NUM>, and the one or more antennas <NUM>, to execute the steps of method <NUM>. As illustrated, the method <NUM> includes a number of enumerated steps, but aspects of the method <NUM> include additional steps before, after, and in between the enumerated steps. In some aspects, one or more of the enumerated steps may be omitted or performed in a different order.

At step <NUM>, continuing on from step <NUM> in <FIG>, the UE may associate the first PUSCH occasion with a first RACH occasion according to an association rule. For example, the UE may associate PUSCH occasion <NUM> with RACH occasion <NUM>, PUSCH occasion <NUM> with RACH occasion <NUM>, and PUSCH occasion <NUM> with RACH occasion <NUM> for <NUM>-step RACH.

At step <NUM>, the UE may determine whether the first PUSCH occasion and the first RACH occasion are valid, e.g., following method <NUM> of <FIG>.

At step <NUM>, when either the PUSCH or the RACH occasion is invalid, method <NUM> proceeds to step <NUM>, at which the UE determines that the PUSCH-RACH occasion pair is invalid. For example, as shown in <FIG>, when PUSCH occasion <NUM> is invalid, the PUSCH-RACH occasion pair <NUM>-<NUM> is deemed invalid. When RACH occasion <NUM> is invalid, the PUSCH-RACH occasion pair <NUM>-<NUM> is deemed invalid.

At step <NUM>, the UE may exclude the invalid PUSCH-RACH pair from the RACH resource pool, and then method <NUM> proceeds to step <NUM> in <FIG>.

At step <NUM>, when neither the PUSCH nor the RACH occasion is invalid, method <NUM> proceeds to step <NUM>, at which the PUSCH-RACH occasion pair is associated with a SSB. For example, the valid PUSCH-RACH occasion pair <NUM>-<NUM> is associated with SSB <NUM>. Method <NUM> then proceeds to step <NUM> in <FIG>.

In some embodiments, if an update is received from the network (e.g., BS <NUM>) that may impact RACH, including any change in <NUM>-step RACH occasion to PUSCH occasion association rule, SSB to RACH occasion association rule, SSB to PUSCH occasion association rule, SSB to MsgA occasion association rule, SSB timing/arrangement, TDD uplink-downlink pattern, and/or the like, the UE may re-validate the PUSCH occasion for <NUM>-step RACH as described in <FIG>, following the updated rules.

Claim 1:
A method of wireless communication, comprising:
receiving (<NUM>), at a user equipment, UE, from a base station, BS, a first configuration of a first random-access channel, RACH, occasion or a first physical uplink shared channel, PUSCH, occasion for a first RACH procedure, and a second configuration of a second RACH occasion for a second RACH procedure;
determining (<NUM>) whether the first PUSCH occasion is valid by:
determining whether the first PUSCH occasion collides with the first RACH occasion or the second RACH occasion by determining whether the first PUSCH occasion overlaps with the first RACH occasion or the second RACH occasion in time and frequency;
determining that the first PUSCH occasion is valid in response to determining that an overlapping area between the first PUSCH occasion and the first RACH occasion or the second RACH occasion is smaller than a threshold ratio portion of the first RACH occasion or the second RACH occasion;
excluding (<NUM>) the first PUSCH occasion from a RACH resource pool for a <NUM>-step RACH procedure in response to determining that the first PUSCH occasion is invalid; and
transmitting (<NUM>), to the BS, a first RACH message using available PUSCH occasions and available RACH occasions;
wherein the first RACH procedure is a <NUM>-step RACH procedure, and the second RACH procedure is a <NUM>-step RACH procedure.