Method of additional prach resource configuration and ra-RNTI determination for prach adaptation

Abstract

A user equipment (UE) can receive a random access channel (RACH) configuration including a first set of parameters to configure a first set of RACH occasions (ROs) and an additional set of parameters to configure an additional set of ROs. The UE may identify the first set of ROs based on a location of the first set of parameters within an information element (IE) structure of the RACH configuration, and generate a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs. The UE may perform a RACH procedure using the validated set of ROs.

Description

METHOD OF ADDITIONAL PRACH RESOURCE CONFIGURATION AND RA-RNTI DETERMINATION FOR PRACH ADAPTATIONFIELD

[0001] This disclosure relates to wireless communication networks including techniques for performing random access procedures within wireless networks.BACKGROUND

[0002] Wireless communication networks may include user equipments (UEs) , base stations, and / or other types of wireless devices capable of communicating with one another. During operation, a UE may communicate with a base station using a random access channel (RACH) to perform operations such as initial access, handover, etc.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings may identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description as other implementations may be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0004] Fig. 1 is a schematic diagram illustrating an example wireless network including a user equipment (UE) configured to identify a first set of RACH occasions (ROs) from a RACH configuration.

[0005] Fig. 2 is a schematic diagram illustrating example signaling between a UE and a base station for performing a RACH procedure based on a validated set of ROs.

[0006] Fig. 3 is a schematic diagram illustrating an example of a resource overlap between a first set of ROs and an additional set of ROs.

[0007] Figs. 4-5 are schematic diagrams illustrating examples of a single RACH configuration generic information element (IE) for configuring the first and additional sets of ROs.

[0008] Figs. 6-7 are schematic diagrams illustrating examples of separate RACH configuration generic IEs for configuring the first set of ROs and the additional set of ROs.

[0009] Fig. 8 is a schematic diagram illustrating an example RACH configuration common IE for configuring the additional set of ROs.

[0010] Figs. 9A-9B and 10A-10B are schematic diagrams illustrating examples of separate RACH configuration common IEs for configuring the first set of ROs and the additional set of ROs.

[0011] Figs. 11A-11B are schematic diagrams illustrating an example structure of a system information block 1 (SIB1) .

[0012] Fig. 12 is a schematic diagram illustrating an example of RO validation based on a set of predefined rules.

[0013] Fig. 13 is a schematic diagram illustrating example signaling between a UE and a base station including an indication of one or more sets of ROs for validation.

[0014] Fig. 14 is a schematic diagram illustrating example signaling between a UE and a base station for transmitting a RACH message with support based on one or more predefined rules.

[0015] Fig. 15 is a schematic diagram illustrating example signaling between a UE and a base station including an indication of features supported by the additional set of ROs.

[0016] Fig. 16 is a schematic diagram illustrating an example of RA-RNTI calculation based on an offset value.

[0017] Fig. 17 is a schematic diagram illustrating an example of determining whether to apply an offset value for RA-RNTI calculation based on ROs within a slot.

[0018] Figs. 18-19 are schematic diagrams illustrating signaling between a UE and a base station to utilize a separate physical downlink control channel (PDCCH) search space for a RACH procedure on the additional set of ROs.

[0019] Fig. 20 is a schematic diagram illustrating an example of RA-RNTI calculation based on a modified frequency identity (ID) .

[0020] Figs. 21-23 are schematic diagrams illustrating examples of modified frequency ID calculation in different slots.

[0021] Fig. 24 is a schematic diagram illustrating an example of signaling between a UE and a base station for determining whether to utilize a modified frequency ID for RA-RNTI calculation.

[0022] Figs. 25-27 are schematic diagrams illustrating examples of modified frequency ID calculation in different slots.

[0023] Fig. 28 is a block diagram illustrating a device that can be employed to utilize a first set of ROs and an additional set of ROs in accordance with some aspects of the present disclosure.

[0024] Fig. 29 is a block diagram illustrating baseband circuitry that can be employed to utilize a first set of ROs and an additional set of ROs in accordance with some aspects of the present disclosure.DETAILED DESCRIPTION

[0025] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings may identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description as other implementations may be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0026] A user equipment (UE) may communicate with a base station using a random access channel (RACH) to perform procedures such as initial access, handover, etc. To support such RACH procedures, the UE may be configured with a plurality of RACH occasions (ROs) identifying time and frequency resources to be used for RACH transmission. The network (e.g., base station) may monitor the RACH channel during the ROs in order to receive potential RACH transmissions from UEs. However, such monitoring may result in the network frequently waking up from sleep to monitor the ROs, resulting in reduced power efficiency, especially during periods of low traffic on the RACH channel. In the effort to improve network energy savings (NES) , one option to reduce energy consumption is for the network to configure a longer periodicity between the ROs, which decreases the frequency with which the network has to wake up to monitor the RACH channel. However, this would increase UE access latency, which negatively impacts the user experience.

[0027] One technique to address these issues is to configure additional set of “adaptive” ROs in combination with the original set of ROs. The adaptive ROs may be configured with a shorter periodicity than the original ROs. As a result, the longer periodicity of the original ROs provides a longer period for the network to sleep, but in case of any need (e.g., during high traffic scenarios) the adaptive ROs can be utilized to provide more RACH resources for UEs to access the network. For example, a downlink control information (DCI) (e.g., paging DCI for radio resource control (RRC) IDLE / INACTIVE UEs or UE specific DCI for RRC CONNECTED UEs) could be used to indicate when the adaptive ROs can be utilized (e.g., when the adaptive ROs are active) . Due to the denser periodicity of the adaptive ROs, the latency of the communication can also be reduced for UEs capable of utilizing the adaptive ROs in certain scenarios.

[0028] Some UEs (e.g., legacy UEs) may be unable to support the configuration of the additional / adaptive PRACH resources. For such UEs, the legacy resources could still be used. For UEs that support the PRACH adaptation, such UEs should be able to differentiate between the legacy and adaptive PRACH resources. For example, a UE may treat the legacy and adaptive resources differently, e.g., prioritizing the use of the legacy resources while only using the adaptive resources when needed.

[0029] Accordingly, the present disclosure relates to techniques to configure additional PRACH resources and identify the additional PRACH resources for resource validation at the UE. In some aspects, a base station transmits a RACH configuration to a UE to configure a first set of ROs and an additional set of ROs. The UE identifies the first set of ROs based on an information element (IE) structure of the RACH configuration, and performs a RACH procedure based on the identification of the first set of ROs. In some examples, the UE generates a validated set of ROs based on a resource overlap between the first and additional sets of ROs , for example, by using different priority levels for the first set of ROs and additional set of ROs, respectively. The UE may initiate a RACH procedure with the base station using RO (s) within the validated set of ROs. Further aspects are disclosed relating to configuring / using additional PRACH resources for different types of RACH procedures (e.g., 2-step RACH or 4-step RACH) and for different types of RACH features (e.g., repetition, redCap, small data transmission (SDT) , etc. ) , and handling of random access radio network temporary identifier (RA-RNTI) collision due to the configuration of the additional PRACH resources.

[0030] Fig. 1 illustrates an example of a wireless network 100 including a UE 101 and a base station 111.

[0031] In some aspects, as shown by act 120, the base station 111 transmits a RACH configuration to the UE 101 to configure one or more sets of ROs. As shown, the one or more sets of ROs may include a first set of ROs 130 and an additional set of ROs 132. In some cases, the additional set of ROs 132 are configured with a denser (e.g., shorter) periodicity than the first set of ROs 130. In the illustrated example, 5 ROs from the additional set of ROs are shown within a time period, while 3 ROs from the first set of ROs are shown within the same time period. Furthermore, the first set of ROs 130 and the additional set of ROs 132 are illustrated as occupying different time and frequency resources. However, in other cases, the first set of ROs 130 and the additional set of ROs may at least partially overlap in time and / or frequency resources.

[0032] The RACH configuration may include one or more sets of parameters to configure the one or more sets of ROs. For example, the RACH configuration includes a first set of parameters to configure the first set of ROs 130, and an additional set of parameters to configure the additional set of ROs 132. Additionally or alternatively, one or more parameters may be shared between the first set of ROs 130 and the additional set of ROs 132 (e.g., used to configure both 130 and 132) . The parameters may comprise information such as a PRACH configuration index, a number of synchronization signal blocks (SSBs) per RO, a number of ROs frequency division multiplexed (FDMed) in a time instance, and / or a frequency start location of the ROs. The parameters may be included within various IEs (e.g., within a same IE, or within different IEs) within the IE structure of the RACH configuration, as discussed in further detail below with reference to Figs. 4-11.

[0033] In some aspects, as shown by act 122, the UE 101 identifies the first set of ROs 130 based on the IE structure of the RACH configuration. In some examples, the first set of ROs 130 correspond to legacy PRACH resources, while the additional set of ROs 130 correspond to adaptive PRACH resources. For example, the UE 101 identifies the first set of ROs 130 as legacy resources by evaluating which IE within the IE structure of the RACH configuration the first set of ROs 130 was configured by. Additionally or alternatively, the base station 111 may transmit an explicit indication of one or more sets of ROs (e.g., using indexes or identifiers corresponding to the one or more sets of ROs) . The UE 101 may identify the one or more sets of ROs provided by the indication as legacy resources. Further details are discussed below with reference to Figs. 4-11.

[0034] In some aspects, as shown by act 124, the UE 101 and the base station 111 perform a RACH procedure based on the identification of the first set of ROs. Depending on a capability of the UE 101, the UE 101 may prioritize using the first set of ROs 130 or the additional set of ROs 132. For example, if the UE 101 does not have a capability to perform PRACH adaptation, the UE 101 may determine to transmit the preamble using the first set of ROs 130 (e.g., legacy resources) . In this case, it is beneficial that the UE 101 is able to accurately identify the legacy resources if it is not capable of using the adaptive resources. If the UE 101 is capable of PRACH adaptation, then the UE 101 may transmit the preamble using either the first set of ROs 130 (e.g., legacy resources) or the additional set of ROs 130 (e.g., adaptive resources) .

[0035] Fig. 2 illustrates an example of signaling between the UE 101 and the base station 111 for performing a RACH procedure. In some aspects, the UE 101 generates a validated set of ROs based on the first set of ROs and the additional set of ROs, and subsequently communicates with the base station 111 using one of the validated ROs.

[0036] At act 120, the UE 101 receives a RACH configuration to configure a first set of ROs and an additional set of ROs, as discussed above with reference to Fig. 1.

[0037] At act 122, the UE 101 identifies the first set of ROs based on the IE structure of the RACH configuration, as discussed above with reference to Fig. 1.

[0038] As shown by act 202, in some aspects the UE 101 generates a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs. The validated set of ROs may include ROs from the first set of ROs and / or the additional set of ROs. For example, the UE 101 begins validation with an initial set of ROs including the first set of ROs and the additional set of ROs, and invalidate one or ROs from the initial set to generate the validated set. In some scenarios, the first set of ROs may at least partially overlap with the additional set of ROs in time and / or frequency. In such scenarios, the UE 101 may invalidate ROs from the first set of ROs or the additional set of ROs within the overlaps, such that the validated set of ROs are non-overlapping in time and frequency. In some examples, the UE 101 prioritizes the first set of ROs by invalidating ROs from the additional set of ROs when an overlap occurs.

[0039] At act 204, the UE 101 and the base station 111 perform a RACH procedure based on the validated set of ROs. For example, the UE 101 may transmit a RACH preamble using one of the validated ROs, and the base station 111 may monitor and receive the preamble on the validated RO.

[0040] Additional RACH messages may further be exchanged based on the type of RACH procedure being performed. For example, in a 4-step RACH procedure, the preamble transmission corresponds to a Msg1. The base station 111 may respond with a random access response (RAR) as a Msg2, and the UE 101 may perform uplink (UL) transmission (e.g., on a physical uplink shared channel (PUSCH) ) in a Msg3. The base station may respond with a contention resolution message as a Msg4.

[0041] Fig. 3 illustrates an example of a resource overlap between a first set of ROs and an additional set of ROs. As shown, the first set of ROs includes ROs 302a, 302b, 302c. The additional set of ROs includes ROs 312a, 312b, 312c, 312d, 312e, 312f. The additional set of ROs has a shorter periodicity than the first set of ROs. The ROs 302a, 302b, 302c from the first set of ROs overlap in time and frequency resources with the ROs 312a, 312c, 312f from the additional set of ROs, respectively. In some examples, the UE 101 prioritizes the first set of ROs (e.g., legacy ROs) for resource validation. As shown, the UE 101 may invalidate the overlapping ROs from the additional set of ROs, corresponding to 312a, 312c, 312f. Invaliding the additional ROs (e.g., adaptive ROs) may be more beneficial for NES, since the network (e.g., base station 111) may already be monitoring the first set of ROs for legacy UEs, which may be incapable of utilizing the additional set of ROs.

[0042] Figs. 4-5 illustrate example IE structures for configuring the first set of ROs and the additional set of ROs. In some aspects, a single RACH configuration generic IE is used to configure the first and additional sets of ROs. The IE structures of Figs. 4-5, for example, may be included in the RACH configuration as previously described.

[0043] With reference to Figs. 4-5, illustrated is a RACH configuration common IE 400 (e.g., RACH-ConfigCommon) , which includes a RACH configuration generic IE 410 (e.g., RACH-ConfigGeneric) . The RACH configuration common IE 400 includes a field 402 for the RACH configuration generic IE 410. Additionally, the IE 400 may further include one or more other parameters 406, which may configure other parameters such as preambles, contention resolution timers, subcarrier spacings, power offsets, etc. for RACH communications.

[0044] The RACH configuration generic IE 410 includes a first PRACH configuration index parameter 412 (e.g., prach-ConfigurationIndex) , a first FDM parameter 414 (e.g., msg1-FDM) , and a first frequency start parameter 416 (e.g., msg1-FrequencyStart) to configure the first set of ROs. In some examples, the parameters 412, 414, 416 are collectively referred to as a first set of parameters.

[0045] The RACH configuration generic IE 410 further includes an additional PRACH configuration index parameter 422 (e.g., prach-ConfigurationIndex-Adaptation) , an additional FDM parameter 424 (e.g., msg1-FDM-Adaptation) , and an additional frequency start parameter (e.g., msg1-FrequencyStart-Adaptation) to configure the additional set of ROs. In some examples, the parameters 422, 424, 426 are collectively referred to as an additional set of parameters.

[0046] The first PRACH configuration index parameter 412 and the additional PRACH index parameter 422 indicate PRACH configuration indexes for the first set of ROs and the additional set of ROs, respectively. A PRACH configuration index may be used by the UE 101 to map a preamble sequence to physical resources during RACH transmission. Depending on the PRACH configuration index, different physical resources (e.g., time and / or frequency resources) may be used.

[0047] The first FDM parameter 414 indicates a number of ROs (e.g., PRACH transmission occasions) FDMed in one time instance for the first set of ROs. The FDMed ROs may occupy the same time resources, but different frequency resources. Similarly, the additional FDM parameter 424 indicates a number of ROs FDMed in one time instance for the additional set of ROs.

[0048] The first frequency start parameter 416 indicates a starting frequency for the first set of ROs, and the additional frequency start parameter 426 indicates a starting frequency for the additional set of ROs. The starting frequency may be defined relative to a lowest frequency RO of a set of ROs (e.g., within the FDMed ROs) . In some examples, the starting frequency is defined relative to a physical resource block (PRB) (e.g., relative to a PRB0) .

[0049] The RACH configuration common IE further includes an SSB per RACH occasion parameter 404 (e.g., ssb-perRACH-Occasion) . The SSB per RACH occasion parameter 404 may indicate a number of SSBs per RO to be used to perform an SSB to RO mapping. For example, each RO may be mapped to one or more SSBs, which may be associated with one or more corresponding beams. The base station 111 may monitor the corresponding beams for the SSBs during the mapped ROs, which may be utilized during RACH procedures such as beam failure recovery. In the example of Fig. 4, the SSB per RACH occasion parameter 404 may be used to configure both the first set of ROs and the additional set of ROs.

[0050] In some examples, the SSB per RACH occasion parameter 404 further configures contention based preambles for the SSBs. For example, the SSB per RACH occasion parameter comprises an ssb-perRACH-OccasionAndCB-PreamblesPerSSB, and further indicates a number of contention based preambles per SSB.

[0051] In some aspects, Fig. 5 resembles Fig. 4, but differs in that a separate SSB per RACH occasion parameter is used to configure the additional set of ROs than the first set of ROs. In the illustrated example, the RACH configuration generic IE 410 further includes an additional SSB per RACH occasion parameter 502 (e.g., ssb-perRACH-Occasion-Adaptation) . The additional SSB per RACH occasion parameter 502 may be used to configure a separate number of SSBs per RO for SSB to RO mapping for the additional set of ROs. The SSB per RACH occasion parameter 404 may be used for the SSB to RO mapping for the first set of ROs, similar to Fig. 4. In the example of Fig. 5, the additional set of parameters may further include the additional SSB per RACH occasion parameter 502.

[0052] Figs. 6-7 illustrate example IE structures for configuring the first set of ROs and the additional set of ROs. In some aspects, separate RACH configuration generic IEs are used to configure the first set of ROs and the additional set of ROs, respectively. The IE structures of Figs. 6-7, for example, may be included in the RACH configuration as previously described.

[0053] With reference to Figs. 6-7, illustrated is a RACH configuration common IE 600 (e.g., RACH-ConfigCommon) , which includes a first RACH configuration generic IE 610 (e.g., RACH-ConfigGeneric) and an additional RACH configuration generic IE 620 (e.g., RACHAdaptation-ConfigGeneric) .

[0054] The RACH configuration common IE 600 includes the field 402 for the RACH configuration generic IE 610, the SSB per RO parameter 404, and optionally may include the other parameters 406. The IE 600 further includes a field 602 for the additional RACH configuration generic IE 620.

[0055] The RACH configuration generic IE 610 includes the first set of parameters, including 412, 414, 416, and optionally may include the other parameters 420. The additional RACH configuration generic IE 620 includes the additional set of parameters, including 422, 424, 426, as previously described.

[0056] In some aspects, as shown in Fig. 6, the additional SSB per RO parameter 502 is included in the RACH configuration common IE 600. In other aspects, as shown in Fig. 7, the additional SSB per RO parameter 502 is included in the additional RACH configuration generic IE 620.

[0057] Fig. 8 illustrates an example IE structure for configuring the first set of ROs and the additional set of ROs. In some aspects, a RACH configuration generic IE 810 includes a first set of parameters to configure the first set of ROs. Furthermore, a RACH configuration common IE 800 includes the RACH configuration generic IE 810, and also directly includes an additional set of parameters to configure the additional set of ROs.

[0058] As shown, the RACH configuration common IE 800 includes the field 402 for the RACH configuration generic IE 810, the SSB per RO parameter 404, and optionally may include the other parameters 406. The RACH configuration generic IE 810 includes the first set of parameters including 412, 414, 416, and may optionally include the other parameters 420.

[0059] The RACH configuration common IE 800 further includes the additional set of parameters including 422, 424, 426. In some examples, the RACH configuration common IE 800 further includes the additional SSB per RO parameter 502. Alternatively, the SSB per RO parameter 404 can be used to configure both the first set of ROs and the additional set of ROs.

[0060] Figs. 9A-9B illustrate an example IE structure for configuring the first set of ROs and the additional set of ROs. Illustrated is an uplink (UL) bandwidth part (BWP) IE 900 (e.g., BWP-UplinkCommon) including a RACH configuration common IE 910 (e.g., RACH-ConfigCommon) and an additional RACH configuration common IE 930 (e.g., RACHAdaptation-ConfigCommon) . The RACH configuration common IE 910 includes a RACH configuration generic IE 920 (e.g., RACH-ConfigGeneric) . In some aspects, the RACH configuration generic IE 920 includes the first set of parameters to configure the first set of ROs, and the additional RACH configuration common IE 930 includes the additional set of parameters to configure the additional set of ROs.

[0061] The UL BWP IE 900 includes a field 902 for the RACH configuration common IE 910 and a field 904 for the additional RACH configuration common IE 930. In some examples, the UL BWP IE 900 further includes one or more other parameters 906, which may include additional RACH configurations (as discussed further in the present disclosure) , and / or configure other parameters for an UL BWP (e.g., a physical uplink control channel (PUCCH) configuration, a PUSCH configuration) .

[0062] The RACH configuration common IE 910 includes the field 402 for the RACH configuration generic IE 920 and the SSB per RO parameter 404. The SSB per RO parameter 404 may be used for SSB to RO mapping for the first set of ROs. Optionally, the RACH configuration common IE 910 may include the one or more other parameters 406, as previously described.

[0063] The RACH configuration generic IE 920 includes the first set of parameters for configuring the first set of ROs, including the parameters 412, 414, 416. Optionally, the RACH configuration generic IE 920 may include the one or more other parameters 420, as previously described.

[0064] The additional RACH configuration common IE 930 includes the additional set of parameters. The additional set of parameters may include one or more of the additional PRACH configuration index parameter 422, the additional FDM parameter 424, the additional frequency start parameter 426, and the additional SSB per RO parameter 502. In some aspects, the additional set of parameters are directly included within the additional RACH configuration common IE 930. For example, there is no intervening IE between the additional RACH configuration common IE 930 and the additional set of parameters.

[0065] Figs. 10A-10B illustrate an example IE structure for configuring the first set of ROs and the additional set of ROs. Figs. 10A-10B resemble Figs. 9A-9B, but differ in that the UL BWP IE 900 includes an additional RACH configuration common IE 1030 in place of the additional RACH configuration common IE 930. In some aspects, the additional set of parameters is included partially within the additional RACH configuration common IE 1030, and partially within an additional RACH configuration generic IE 1040 within the RACH configuration common IE 1030. In the illustrated example, the additional RACH configuration common IE 1030 includes the additional SSB per RO parameter 502, and a field 1002 for the additional RACH configuration generic IE 1040. The additional RACH configuration generic IE 1040 includes the PRACH configuration index 422, the FDM parameter 424, and the frequency start parameter 426.

[0066] Figs. 11A-11B illustrate an example IE structure of a system information block 1102. In some examples, the SIB 1102 comprises a system information block 1 (SIB1) .

[0067] In some aspects, the SIB 1102 comprises a serving cell configuration IE 1104 (e.g., ServingCellConfigCommonSIB) . The serving cell configuration IE 1104 comprises a UL configuration IE 1106 (e.g., UplinkConfigCommonSIB) , which may configure parameters for UL communication. Although not shown for simplicity, the serving cell configuration IE 1104 may comprise one or more other IEs for SIB configuration, for example, to configure parameters for downlink (DL) communication, supplementary uplink (SUL) , etc. The UL configuration IE 1106 includes an UL BWP IE 1108 (e.g., BWP-UplinkCommon) , which may be UL BWP IE as previously described.

[0068] The UL BWP IE 1108 includes a RACH configuration common IE 1110 (e.g., RACH-ConfigCommon) , a MsgA RACH configuration common IE 1120 (e.g., MsgA-ConfigCommon-r16) , and an additional RACH configuration list 1130 (e.g., AdditionalRACH-ConfigList-r17) .

[0069] The RACH configuration common IE 1110 includes a RACH configuration generic IE 1112 (e.g., RACH-ConfigGeneric) . The RACH configuration common IE 1110 and the RACH configuration generic IE 1112 may include one of the RACH configuration common IEs and one of the RACH configuration generic IEs as described with reference to Figs. 4-10. The RACH configuration common IE 1110 further includes a feature combination preambles list 1114 (e.g., featureCombinationPreamblesList-r17) . The features combination preambles list 1114 may include one or more feature combination preambles IEs each indicating an association between a set of preambles with a feature combination. The configured preambles may be used by the UE 101 during the initial preamble transmission for a RACH procedure using a feature combination. A feature combination may include one more additional RACH features, for example, redCap, small data transmission, repetitions, etc. Each feature combination preambles IE may further include an SSB shared RO mask index IE 1116 (e.g., ssb-SharedRO-MaskIndex-r17) , which may indicate a subset of ROs where preambles are allocated for the feature combination configured by the corresponding feature combination preambles IE.

[0070] The MsgA RACH configuration common IE 1120 includes a 2-step RACH configuration common IE 1122 (e.g., RACH-ConfigCommonTwoStepRA) , which includes a 2-step RACH configuration generic IE 1124 (e.g., RACH-ConfigGenericTwoStepRA-r16) . The 2-step RACH configuration common IE 1122 further includes a MsgA-SSB-SharedRO-MaskIndex-r16 IE 1126, which may configure a subset of ROs for the 2-step RACH configuration. The IE 1122 further includes a feature combination preambles list 1128 and a SSB shared RO mask index 1129, which may function similarly to the feature combination preambles list 1114 and the SSB shared RO mask index 1116 but in the context of the 2-step RACH configuration.

[0071] In some aspects, the configuration of additional ROs in Figs. 4-10 can be extended to 2-step RACH configuration (e.g., if PRACH adaptation is supported for 2-step RACH) . For example, an additional parameters (e.g., similar to 412, 414, 416, and / or 502) may be included in the 2-step RACH configuration generic IE 1124 (e.g., similar to the RACH configuration generic IE of Figs. 4-10) , the 2-step RACH configuration common IE (e.g., similar to the RACH configuration common IE of Figs. 4-10) , or a combination.

[0072] The additional RACH configuration list 1130 may also optionally be included in the UL BWP IE 1108. When present, the additional RACH configuration list 1130 includes one or more RACH configuration common IEs 1132 and / or one or more MsgA configuration common IEs 1134. The additional RACH configuration list 1130 may be used to configure further PRACH resources (e.g., ROs) than the resources configured by the RACH configuration common IE 1110 and the MsgA configuration common IE 1120. Although not shown for simplicity, the RACH configuration common IEs (in 1132) and the MsgA configuration common IEs (in 1134) may have a similar structure and provide similar information as the RACH configuration common IE 1110 and the MsgA configuration common IE 1120. In some examples, additional sets of parameters are also included within the IEs 1132 and / or 1134 within the additional RACH configuration list 1130 to configure additional (e.g., adaptive) ROs according to the techniques discussed throughout the present disclosure.

[0073] Fig. 12 illustrates an example of the UE 101 performing RO validation. In some aspects, the UE 101 performs the RO validation based on a set of predefined rules.

[0074] At act 1202, the base station 111 transmits a RACH configuration to the UE 101. The RACH configuration may be the RACH configuration as described throughout the present disclosure, and may configure one or more sets of ROs.

[0075] At act 1204, the UE 101 identifies one or more sets of ROs (e.g., from the configured ROs) for validation based on an IE structure of the RACH configuration and a set of predefined rules. In some examples, the UE 101 identifies one or more sets of resources (e.g., corresponding to legacy resources) , and performs RO validation based on the identified sets of ROs.

[0076] In some examples, the set of predefined rules includes identifying the PRACH resource configured by the RACH configuration common IE in SIB1. For example, the UE 101 identifies the ROs configured by the RACH-ConfigCommon IE 1110 as legacy resources.

[0077] In some examples, the set of predefined rules include identifying a PRACH resource configured in a same RACH configuration generic IE. For example, if the RACH configuration generic IE configures both a first set of ROs and an additional set of ROs, the UE 101 may identify the first set of ROs based on the parameters used to configure the first set of ROs. In the context of Fig. 4, different parameters are used to configure the first set of ROs and the additional set of ROs, which may be used by the UE 101 to identify the first set of ROs. As shown in Fig. 4, the first set of parameters include prach-ConfigurationIndex, msg1-FDM, and msg1-FrequencyStart, while the additional set of parameters include prach-ConfigurationIndex-Adaptation, msg1-FDM-Adaptation, and msg1-FrequencyStart-Adaptation. Thus, the UE 101 may identify the ROs configured by prach-ConfigurationIndex, msg1-FDM, and msg1-FrequencyStart as the first set of ROs. Although the term “adaptation” is used to distinguish between the first and additional sets of parameters, it will be appreciated that this naming scheme is merely exemplary, and that alternative nomenclature may be used without departing from the scope of the present disclosure.

[0078] In some examples, the set of predefined rules include identifying a PRACH resource configured in a same RACH configuration common IE. For example, if the RACH configuration common IE configures both a first set of ROs and an additional set of ROs, the UE 101 may identify the first set of ROs based on the parameters and / or IEs used to configure the first set of ROs. For example, in the context of Fig. 6, the RACH-ConfigGeneric IE is used to configure the first set of ROs, while the RACHAdaptation-ConfigGeneric IE is used to configure the additional set of ROs. The RACH-ConfigGeneric IE and the RACHAdaptation-ConfigGeneric IE may have a different structure and / or different IE identifiers (IEIs) , such that the UE 101 can distinguish between the first set of ROs and the additional set of ROs, based on which IE was used to configure each set of ROs.

[0079] Various combinations of the above-described predefined rules may be utilized by the UE 101 to identify the one or more sets of ROs. In one example, the UE 101 identifies the PRACH resource configured in RACH-ConfigCommon In SIB1 as a baseline operation, and can further identify the PRACH resources configured by a same RACH configuration common or a same RACH configuration generic. Further, these rules are not limited to 4-step RACH (e.g., RACH-ConfigCommon and RACH-ConfigGeneric) , but may additionally or alternatively be applied to 2-step RACH (e.g., MsgA-ConfigCommon, RACH-ConfigCommonTwoStepRA, RACH-ConfigGenericTwoStepRA) . Further, the RACH configuration common IE is not limited to the example of Fig. 4, and the RACH configuration generic IE is not limited to the example of Fig. 6, but may be applied to other RACH configuration common or RACH configuration generic IEs discussed throughout the present disclosure. For example, the UE 101 could identify PRACH resources configured by the RACH configuration common IE 1132 or the MsgA configuration common IE 1134 within the additional RACH configuration list 1130 based on the rules discussed above.

[0080] Fig. 13 resembles Fig. 12, but differs in that it includes act 1302 in place of act 1204. In some aspects, the base station 111 transmits an indication of one or more sets of ROs for validation. For example, the base station 111 could indicate whether the PRACH resources configured in RACH-ConfigCommon in SIB1 should be used for validation, or whether additional PRACH resources (e.g., configured in AdditionalRACH-ConfigList-r17) should be used for the validation. For the additional PRACH resources, the base station 111 could indicate each resource using an index, or a bitmap. For example, the index could point to an ith resource in the additional RACH configuration list, where i is the position of the resource within the additional RACH configuration list. In the case of a bitmap, the ith bit in the bitmap could correspond to the ith resource within the list. In some examples, the base station 111 has the ability to the transmit the explicit indication at act 1302, or omit the transmission of the explicit indication of act 1302. In the latter example, the UE 101 may fallback to the operation as discussed with reference to Fig. 12 when identifying resources for validation.

[0081] Fig. 14 illustrates an example of a UE 101 performing a RACH procedure with support based on one or more predefined rules. In some aspects, the UE 101 determines whether one or more RACH features (e.g., redCap, SDT, repetition) are supported on the additional set of ROs based on one or more predefined rules, and transmits a RACH message using resources from the additional set of ROs based on the determination. Additionally or alternatively, the UE 101 may determine whether different types of RACH procedures and / or functionalities are supported on the additional ROs. For example, different types of RACH procedures may include a 4-step RACH and a 2-step RACH. Different functionalities may include a contention based random access (CBRA) procedure and a contention free random access (CFRA) procedure, for example.

[0082] At act 1402, the base station 111 transmits a RACH configuration to the UE 101 to configure the first set of ROs and the additional set of ROs, as previously described.

[0083] At act 1404, the UE 101 transmits a RACH message using an RO of the additional set of ROs, with support based on one or more predefined rules.

[0084] In some examples, the one or more predefined rules include only a 4-step RACH procedure being supported on the additional PRACH resources (e.g., the additional ROs) . For example, even if a 2-step RACH is configured in a MsgA-ConfigCommon-r16 in the same BWP-UplinkCommon and has a shared RO with the 4-step RACH, the 2-step RACH is still performed on the legacy resources (e.g., the first set of ROs) . In some examples, the one or more predefined rules include a default behavior to not use the additional ROs for additional RACH features (e.g., SDT, redCap, repetition) .

[0085] In some examples, the one or more predefined rules include supporting 2-step RACH on the additional set of ROs (e.g., adaptive ROs) based on a shared RO configuration. For example, if shared ROs are used for 4-step and 2-step RACH on the first set of ROs, then 2-step RACH can also be supported on the additional set of ROs. For example, shared ROs may refer to a set of ROs that is shared for a 4-step and a 2-step RACH configuration (e.g., a same PRACH configuration index is used to configure the 4-step and 2-step ROs) . Different sets of RACH preambles may be configured for 4-step RACH and 2-step RACH on the shared ROs, respectively.

[0086] In some examples, the one or more predefined rules include supporting one or more features based on a features combination list. For example, the additional feature combinations indicated by a featureCombination IE within a FeatureCombinationPreambles IE within the RACH-ConfigCommon IE can also use the additional set of ROs. In this case, the PRACH resources may be shared with legacy resources. For example, the feature combinations may share ROs with other features, and use preambles to differentiate between the different features on the shared ROs. For the additional features in the feature combinations, they may also use the additional PRACH resources.

[0087] In some examples, if additional or adaptive ROs are configured in a 2-step RACH configuration, then the 2-step RACH can also be performed on the additional ROs. The 2-step RACH configuration may include, for example, one or more of the IEs 1120, 1122, 1124, 1134 of Figs. 11A-11B. For example, the 2-step RACH configuration includes a RACH-ConfigCommonTwoStepRA IE, RACH-ConfigGenericTwoStepRA-r16 IE, MsgA-ConfigCommon-r16 IE, or any one of the aforementioned IEs within an additional RACH configuration list (e.g., AdditionalRACH-ConfigList-r17) . Furthermore, one or more feature combinations may be configured for the 2-step RACH (e.g., in features combination preambles list 1128) . In a further example, the one or more predefined rules can include a default behavior that the feature combinations cannot use the additional ROs. In another example, the one or more predefined rules include a rule that the feature combinations are allowed to use the additional ROs. Additionally or alternatively, the base station 111 could transmit an indication to the UE 101 (discussed in further detail with reference to Fig. 15) to indicate which features combinations can use the additional set of ROs.

[0088] In some examples, for ROs configured by an additional RACH configuration list (e.g., 1130) , 4-step and / or 2-step RACH can be supported according to the techniques previously described. For example, in a 4-step RACH configuration (e.g., RACH-ConfigCommon) of the additional RACH configuration list, only 4-step RACH could be supported on the additional set of ROs for the feature combination indicated in the RACH-ConfigCommon IE. Additionally or alternatively, 2-step RACH could also be supported for the indicated feature combination if shared ROs are configured for the 4-step and 2-step RACH. In another example, the additional feature combinations indicated by a feature combination (e.g., featureCombination within FeatureCombinationPreambles) in the RACH configuration common IE can also use the additional PRACH resources. Additionally or alternatively, the base station 111 could transmit an indication to the UE 101 (discussed in further detail with reference to Fig. 15) to indicate which features combinations can use the additional set of ROs.

[0089] In some examples, the base station 111 transmits a PDCCH order to the UE 101 to trigger a preamble transmission corresponding to the RACH message of act 1404. For example, the PDCCH order comprises a downlink control information (DCI) format 1_0 with a cell radio network temporary identifier (C-RNTI) used to trigger the preamble transmission. Furthermore, the DCI may include a 1-bit field indicating whether the additional PRACH resources (e.g. additional set of ROs) are available for the triggered PRACH (e.g., preamble) transmission. In some alternative examples, the predefined rules include a UE behavior to select the closest RACH resource, regardless of whether it is in the first set of ROs or the additional set of ROs. For example, the closest RACH resource is the closest RACH resource occurring in time after the PDCCH order, which may result in the lowest latency. In some examples, the predefined rules include a default UE behavior to utilize the additional PRACH resources when the PDCCH order indicates that the additional PRACH resources are available. Additionally or alternatively, an indication could be provided (e.g., a 1-bit indication) by the base station 111 to the UE 101 to indicate whether to use the additional PRACH resources, or whether to use the closest PRACH resources. In some aspects, instead of a PDCCH order another type of PDCCH transmission is used, for example, for a UE in an RRC IDLE or an RRC INACTIVE state.

[0090] Fig. 15 illustrates an example RACH procedure. In some aspects, the base station 111 transmits an indication of features supported by the additional set of ROs to the UE 101.

[0091] At act 1502, the base station 111 transmits a RACH configuration to the UE 101 to configure the first set of ROs and the additional set of ROs, as previously described.

[0092] At act 1504, the base station transmits an indication of which features can use the additional set of ROs. For example, the base station may indicate one or more of the previously described additional features (e.g., SDT, redCap, repetition) .

[0093] At act 1506, the UE 101 transmits a RACH message to the base station 111 on the additional set of ROs based on the indication. For example, the UE 101 may utilize the additional RACH features during the transmission for which support was indicated at act 1504. In some examples, the UE 101 uses a preamble start index configured in the feature combination preambles list (e.g., featureCombinationPreamblesList-r17) when performing the transmission.

[0094] Fig. 16 illustrates an example of RA-RNTI calculation based on an offset value. During a RACH procedure, an RA-RNTI may be associated with an RO in which the random access preamble was transmitted. The RA-RNTI calculation for an associated RO may be performed based on one or more variables related to the RO. For example, the RA-RNTI can be calculated using a formula RA-RNTI = 1 + s_id + 14 *t_id + 14 *80 *f_id + 14 *80 *8 *ul_carrier_id, where s_id is a symbol ID associated with the RO, t_id is a slot associated with the RO, f_id is based on frequency domain resources of the RO, and ul_carrier_id is based on an UL carrier used for the preamble transmission on the RO. For example, s_id is the index of a first orthogonal frequency division multiplexing (OFDM) symbol of the RO, t_id is the index of the first slot of the RO (e.g., in a system frame) , f_id is the index of the RO in the frequency domain, and the ul_carrier_id is the ID of the UL carrier used for the preamble transmission.

[0095] In some cases, RA-RNTI calculation based solely on such variables may lead to RA-RNTI ambiguity when utilizing the first and additional sets of ROs. For example, if the first and additional sets of ROs utilize a same UL carrier and overlap in time and frequency resources, the s_id, t_id_, f_id, and ul_carrier_id values may be the same, resulting in the same RA-RNTI calculation. Such RA-RNTI ambiguity may cause issues when determining which RACH features are supported on the corresponding RO. For example, if certain RACH features are supported on the first set of ROs but not on the additional set of ROs, the UE 101 and the base station 111 should be able to properly distinguish between the sets of ROs, e.g., using the RA-RNTI.

[0096] Accordingly, in some aspects, the UE 101 and / or the base station 111 calculate an RA-RNTI based on an offset value. In some aspects, different offset values are used for the first set of ROs and the additional set of ROs. As a result, the RA-RNTI calculation will be different for ROs in the first set of ROs and ROs in the additional set of ROs, even if other parameters (e.g., s_id, t_id, f_id, ul_carrier_id) are the same due to resource overlapping and partially shared RACH configuration. Alternatively, an offset value may be used for one set of ROs (e.g., first set of ROs or additional set of ROs) , and no offset value is used for the other set of ROs (e.g., additional set of ROs or first set of ROs, respectively) . The offset value may comprise a k_offset value, and the RA-RNTI calculation may further be based on one or more of time domain parameters (e.g., symbol and / or slot parameters) , a frequency domain parameter, or an UL carrier associated with the RO. For example, the RA_RNTI is calculated based on an equation RA-RNTI = 1 + s_id + 14 *t_id + 14 *80 *f_id + 14 *80 *8 *ul_carrier_id + 14 *80 *8 *k_offset, where k_offset is the appropriate offset value as discussed above.

[0097] As shown by act 1602, in some aspects, the base station 111 transmits an indication of an offset value for RA-RNTI calculation to the UE 101. For example, the base station 111 may indicate or configure an offset value for the first set of ROs, the additional set of ROs, or both the first and additional sets of ROs (e.g., with different values, respectively) . If multiple sets of adaptive ROs are configured, each set may be configured with a different offset value. In some examples, the offset value is indicated in a SIB1 (e.g., SIB 1102) . For example, the offset value may be indicated in a RACHAdaptation-ConfigGeneric IE (e.g., 620, 1040) or RACHAdaptation-ConfigCommon IE (e.g., 930, 1030) .

[0098] In some alternative aspects, act 1602 is omitted, and the UE 101 and base station 111 perform the RA-RNTI calculation based on one or more predefined offset values. For example, one or more k_offset values can be defined in 3rd Generation Partnership Project (3GPP) specifications, corresponding to the first set of ROs (e.g., legacy ROs) and / or the additional set of ROs (e.g., ROs for PRACH adaptation) . In some examples, different k offset values are defined for different sets of additional (e.g., adaptive) ROs.

[0099] At act 1604, the UE 101 and the base station 111 perform a RACH procedure based on the calculated RA-RNTI. For example, the UE 101 may transmit a preamble (e.g., Msg1) to the base station 111, and monitor for an RAR (e.g., Msg2) based on the calculated RA-RNTI.

[0100] Fig. 17 illustrate another example of RA-RNTI calculation based on an offset value. As shown, similar to Fig. 16, Fig. 17 contains act 1602. As shown by act 1702, in some aspects, the UE 101 and / or the base station 111 determine whether to apply the offset value for RA-RNTI calculation based on ROs within a slot. For example, when calculating the RA-RNTI for a corresponding RO, the determination is based on which other ROs are in the same slot as the corresponding RO. In some examples, if the slot contains legacy ROs (e.g., from the first set of ROs) and adaptive ROs (e.g., from the additional set of ROs) , then the offset value is applied for the RA-RNTI calculation. Alternatively, as discussed with reference to Fig. 16, the offset value may be applied without the determination step at act 1702. For example, the offset value of Fig. 16 is applied to all time instances irrespective to whether multiple RACH resource configurations exist or not. At act 1704, the UE 101 and the base station 111 perform a RACH procedure using an RA-RNTI based on the determination.

[0101] Figs. 18-19 illustrate examples of monitoring for a RAR during a RACH procedure on the additional set of ROs using a separate PDCCH search space. Another possible solution to the RA-RNTI ambiguity issue is to use a separate PDCCH search space for the adaptive set (s) of ROs than for the legacy ROs. By using a different PDCCH search space, the UE 101 can properly identify the RAR during a RACH procedure on the additional set of ROs (e.g., by referring to the search space in which the RAR was received) , even if the calculated RA-RNTI would be the same as on the first set of ROs.

[0102] With reference to Fig. 18, at act 1802, the base station 111 transmits a RACH configuration to the UE 101 to configure the first set of ROs and the additional set of ROs, as described throughout the present disclosure.

[0103] At act 1804, the base station 111 transmits a configuration to the UE 101 to configure a separate PDCCH search space for the additional set of ROs. For example, the separate PDCCH search space is configured by a PDCCH-ConfigCommon IE. In some examples, the separate PDCCH search space is a new PDCCH search space specifically dedicated to additional / adaptive PRACH resources.

[0104] At act 1806, the UE 101 transmits a PRACH preamble on an RO of the additional set of ROs. At act 1808, the UE 101 monitors for an RAR in the separate PDCCH search space. For example, the UE 101 monitors the separate PDCCH search space for the RAR in response to selecting resources from the additional set of ROs for the preamble transmission at act 1806. In some examples, the UE 101 monitors for a DCI format 1_0 with a cyclic redundancy check (CRC) scrambled by an RA-RNTI, which may correspond to the RAR message. For preamble transmission on the first set of ROs, the UE 101 may monitor for the RAR in the legacy PDCCH search space.

[0105] With reference to Fig. 19, in some aspects, act 1804 is optionally omitted. For example, the base station 111 optionally configures the separate PDCCH search space, in which case the operation of Fig. 18 is performed. If the base station 111 does not configure the separate PDCCH search space, however, several other options can be considered. For example, at act 1908, the UE 101 could monitor for the RAR using a type-1 PDCCH common search space (CSS) . Alternatively, other options could be applied to solve the RA-RNTI ambiguity, such as using a k offset value for the RA-RNTI calculation (e.g., Figs. 16-17) , or using a modified frequency ID for the RA-RNTI calculation, as discussed below with reference to Fig. 20.

[0106] Fig. 20 illustrates an example of RA-RNTI calculation based on a modified frequency ID value. In some aspects the UE 101 and / or the base station 111 calculate a modified frequency ID value based on ROs from the first set of ROs and ROs from the additional set of ROs within a slot. The slot may be the slot that contains the RO corresponding to the calculated RA-RNTI value.

[0107] At act 2002, the base station 111 transmits a RACH configuration for the first set of ROs and the additional set of ROs to the UE 101, as described throughout the present disclosure.

[0108] At act 2004, the UE 101 calculates a modified frequency ID value based on a number of ROs from the additional set of ROs FDMed within a slot. For example, the modified frequency value is calculated using the equation f_id_additional = msg1-FDM + f_id, where f_id_additional is the modified frequency ID value, msg1-FDM is the number of ROs from the first set of ROs FDMed in the slot, and f_id is the original frequency ID to be used for the RA-RNTI calculation. The value of msg1-FDM, for example, is provided in the first set of parameters as previously described. The first set of ROs, for example, may correspond to legacy or non-adaptive ROs. The original frequency ID f_id may be calculated according to rules defined in 3GPP specifications. Although not shown for simplicity, the base station 111 may perform a similar procedure to calculate the modified frequency ID value.

[0109] At act 2006, the UE 101 calculates the RA-RNTI based on the modified frequency value. Furthermore, the RA-RNTI calculation may further be based on one or more of a time domain ID (e.g., symbol and / or slot ID) , a frequency domain ID, or an UL carrier ID, as previously described. In some examples, the RA-RNTI is calculated using the equation RA-RNTI = 1 + s_id + 14 *t_id + 14 *80 *f_id_additional + 14 *80 *8 *ul_carrier_id. Although not illustrated for simplicity, the base station 111 may perform a similar procedure to calculate the RA-RNTI. At act 2008, the UE 101 and the base station 111 perform a RACH procedure using the calculated RA-RNTI.

[0110] Figs. 21-23 illustrate examples of the modified frequency ID discussed with reference to Fig. 20.

[0111] With reference to Fig. 21, in some aspects, the modified frequency ID is applied to all slots. For example, the modified frequency ID is calculated and applied for RA-RNTI calculation in all time instances, regardless of whether multiple RACH configurations (e.g., legacy and adaptive) exist or not. As shown in a first slot 2102 the ROs RO1, RO2, RO3, RO4 of the first set of ROs have frequency ID values of 0, 1, 2, 3 respectively. In this case, the number of ROs from the first set of ROs FDMed in the slot 2102 is 4 (e.g., msg1-FDM = 4) . Further, in the first slot 2102 the ROs RO1, RO2, RO3, RO4 of the additional set of ROs have modified frequency ID values of 4, 5, 6, 7 respectively. The modified frequency ID values are calculated based on original frequency ID values 0, 1, 2, 3 plus an offset of 4, which corresponds to the value of msg1-FDM. The slot 2104 contains ROs from the additional set of ROs, but does not contain ROs from the first set of ROs. In the illustrated example, the modified frequency ID is still calculated using the value of msg1-FDM, resulting in modified frequency ID values of 4, 5, 6, 7 respectively for RO1, RO2, RO3, RO4 of the additional set of ROs. Further illustrated is a slot 2106 and a slot 2108. The slot 2106 contains ROs arranged in a similar manner as the slot 2102, and thus may also utilize a similar frequency ID calculation as the slot 2102. The slot 2108 contains ROs arranged in a similar manner as the slot 2104, and thus may also utilize a similar frequency ID calculation as the slot 2104.

[0112] Fig. 22 illustrates a variation of Fig. 21 where the first set of ROs and the additional set of ROs are overlapping in time and frequency. In some aspects, the frequency ID numbering for the additional set of ROs begins with non-overlapping ROs from the additional set of ROs. For example, the RO1 and RO2 of the additional set of ROs (overlapping with RO3 and RO4 of the first set of ROs) are not considered for the frequency ID numbering. As shown in Fig. 22, the RO3 of the additional set of ROs has a frequency ID value of 4+0, and the RO4 of the additional set of ROs has a frequency ID value of 4+1.

[0113] Similar to Fig. 21, the RO1, RO2, RO3, and RO4 of the first set of ROs have frequency IDs of 0, 1, 2, 3, 4, respectively. However, Fig. 22 differs in that the RO1 and RO2 from the additional set of ROs are overlapping in time and frequency with the RO3 and RO4 of the first set of ROs. In some examples, the UE 101 prioritizes using ROs from the first set of ROs (e.g., RO3, RO4) and invalidates the overlapping ROs from the additional set of ROs (e.g., RO1, RO2) , as previously described. The slot 2204 only contains ROs from the additional set of ROs, and thus follows the frequency ID numbering scheme discussed with reference to the slot 2104 of Fig. 21. Similar to Fig. 21, the frequency ID numbering of slots 2202, 2204 may repeat in slots 2206, 2208, respectively.

[0114] With reference to Fig. 23, in some aspects, the frequency ID numbering includes assigning lower numbers to the first set of ROs (e.g., legacy resources) first, and assigning higher numbers to the additional set of ROs (e.g., adaptive resources) second, in ascending order. As shown, the slot 2302 contains RO1 and RO2 from the additional set of ROs, and RO1-RO4 from the first set of ROs. The RO3 and RO4 of the additional set of ROs are overlapping with the first set of ROs, and thus are not considered for the frequency ID numbering. The frequency ID numbering begins with 0, 1, 2, 3 corresponding to RO1, RO2, RO3, RO4 of the first set of ROs, respectively. The frequency ID numbers 4, 5 correspond to the RO1 and the RO2 of the additional set of ROs, respectively. Thus, in Fig. 23, the frequency ID ordering is not necessarily aligned with frequency ordering, but rather maps lower numbers to the first set of ROs and higher numbers to the additional set of ROs. For example, the frequency ID ordering is assigned based on the associated RO set first, and based on the frequency location within the RO set second.

[0115] Fig. 24 illustrates an example of signaling between the UE 101 and the base station 111 for determining whether to utilize a modified frequency ID value for RA-RNTI calculation. In some aspects, the UE 101 determines whether to apply the modified frequency ID value for the RA-RNTI calculation based on a resource overlap between the firsts set of ROs and the additional set of ROs within a slot.

[0116] At act 2402, the base station 111 transmits a RACH configuration to configure the first set of ROs and the additional set of ROs, as described throughout the present disclosure.

[0117] At act 2404, the UE 101 determines whether to apply a modified frequency ID value for RA-RNTI calculation based on a resource overlap between the first set of ROs and the additional set of ROs within a slot. In some examples, the UE 101 applies the modified frequency ID value based on whether a slot contains ROs from both the first set of ROs and the additional set of ROs. For example, if the slot used for preamble transmission contains ROs from the first set of ROs and ROs from the additional set of ROs, the UE 101 may apply the modified frequency ID value. If the slot contains only ROs from the additional set of ROs, or only ROs from the first set of ROs, the UE 101 may determine to not apply the modified frequency ID value to the RA-RNTI calculation. When utilizing the modified frequency ID value the UE may calculated the modified frequency ID value, for example, using the techniques discussed with reference to Fig. 20. At act 2406 the UE 101 calculates the RA-RNTI based on the determination from act 2404. Although not illustrated for simplicity, the base station 111 may also make a determination similar to act 2404 and / or a calculation similar to act 2406 when performing the RACH procedure. At act 2408, the UE 101 and the base station 111 perform a RACH procedure using the calculated RA-RNTI.

[0118] Figs. 25-27 illustrate examples of the modified frequency ID discussed with reference to Fig. 24.

[0119] With reference to Fig. 25, illustrated is a slot 2502 containing RO1, RO2, RO3, RO4 from the first set of ROs and RO1, RO2, RO3, RO4 from the additional set of ROs. The modified frequency ID is applied to the slot 2502, resulting in frequency ID values of 0, 1, 2, 3 corresponding to RO1, RO2, RO3, RO4 of the first set of ROs, and frequency ID values of 4, 5, 6, 7 corresponding to RO1, RO2, RO3, RO4 of the additional set of ROs. The slot 2504 contains ROs from the additional set of ROs, but not from the first set of ROs. As discussed with reference to Fig. 24, the modified frequency ID is not used for RA-RNTI calculation, and frequency ID values of 0, 1, 2, 3 are assigned to RO1, RO2, RO3, RO4 respectively of the additional set of ROs in the slot 2504. The frequency ID numbering of the slots 2506, 2508 may resemble the frequency ID numbering in slots 2502, 2504, respectively.

[0120] With reference to Fig. 26, in some aspects, the modified frequency ID numbering is applied to the first set of ROs and non-overlapping ROs from the additional set of ROs. As shown in the slot 2602, frequency ID values of 0, 1, 2, 3 are assigned to RO1, RO2, RO3, RO4 of the first set of ROs, respectively. The RO1 and RO2 of the additional set of ROs are overlapping with the first set of ROs, and are not considered for the frequency ID numbering. The RO3 and RO4 of the additional set of ROs are assigned frequency ID values of 4 and 5, respectively (e.g., using an offset of the msg1-FDM value) . The slot 2604 contains ROs from the additional set of ROs, but not ROs from the first set of ROs. As discussed with reference to Fig. 24, the modified frequency ID is not used for RA-RNTI calculation. Thus, the modified frequency ID numbering is not applied, and the RO1, RO2, RO3, RO4 of the additional set of ROs are assigned frequency ID values of 0, 1, 2, 3, respectively. The frequency ID numbering of slot 2606 may follow slot 2602, and the frequency ID numbering in slot 2608 may follow slot 2604.

[0121] With reference to Fig. 27, the frequency ID numbering may be performed firstly on the first set of ROs, and secondly on the additional set of ROs. For example, the lower frequency ID numbers are assigned to the first set of ROs, and the higher frequency ID numbers are assigned to the additional set of ROs. In slot 2702, the RO1, RO2, RO3, RO4 of the first set of ROs are assigned frequency ID values of 0, 1, 2, 3. The RO1 and RO2 of the additional set of ROs in the slot 2702 are assigned frequency ID values of 4 and 5 (e.g., using an offset of the msg1-FDM value) . As discussed with reference to Fig. 24, the modified frequency ID is not used for RA-RNTI calculation in the slot 2704, which contains ROs from the additional set of ROs but not from the first set of ROs. Accordingly, in the slot 2704, the RO1, RO2, RO3, RO4 of the additional set of ROs are assigned frequency ID numbers of 0, 1, 2, 3, respectively. The frequency ID numbering of slot 2706 may follow slot 2702, and the frequency ID numbering of slot 2708 may follow slot 2704.

[0122] Fig. 28 is a diagram illustrating example components of a device 2800 that can be employed in accordance with some aspects of the present disclosure. In some aspects, the device 2800 can include application circuitry 2802, baseband circuitry 2804, Radio Frequency (RF) circuitry 2806, front-end module (FEM) circuitry 2808, one or more antennas 2810, and power management circuitry (PMC) 2812 coupled together at least as shown. The components of the illustrated device 2800 can be included in a UE or a RAN node such as the UE 101 or the base station 111 as described throughout the present disclosure. The UE 101 and the base station 111 may be configured to communicate using a first set of ROs and an additional set of ROs, as described throughout the present disclosure. In some implementations, the device 2800 can include fewer elements (e.g., a RAN node may not utilize application circuitry 2802 and instead include a processor / controller to process IP data received from a CN, which may be a 5GC or an Evolved Packet Core (EPC) ) . In some implementations, the device 2800 can include additional elements such as, for example, memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 2800, etc. ) , or input / output (I / O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

[0123] The application circuitry 2802 can include one or more application processors. For example, the application circuitry 2802 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor (s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors can be coupled with or can include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 2800. In some implementations, processors of application circuitry 2802 can process IP data packets received from an EPC.

[0124] The baseband circuitry 2804 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 2804 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 2806 and to generate baseband signals for a transmit signal path of the RF circuitry 2806. Baseband circuitry 2804 can interface with the application circuitry 2802 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 2806. For example, in some implementations, the baseband circuitry 2804 can include a 3G baseband processor 2804A, a 4G baseband processor 2804B, a 5G baseband processor 2804C, or other baseband processor (s) 2804D for other existing generations, generations in development or to be developed in the future (e.g., 2G, 6G, etc. ) .

[0125] The baseband circuitry 2804 (e.g., one or more of baseband processors 2804A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 2806. In other implementations, some or all of the functionality of baseband processors 2804A-D can be included in modules stored in the memory 2804G and executed via a Central Processing Unit (CPU) 2804E. The radio control functions can include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some implementations, the baseband circuitry 2804 can include one or more audio digital signal processor (s) (DSP) 2804F.

[0126] RF circuitry 2806 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, the RF circuitry 2806 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 2806 can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry 2808 and provide baseband signals to the baseband circuitry 2804. RF circuitry 2806 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by the baseband circuitry 2804 and provide RF output signals to the FEM circuitry 2808 for transmission.

[0127] In some implementations, the receive signal path of the RF circuitry 2806 can include mixer circuitry 2806A, amplifier circuitry 2806B and filter circuitry 2806C. In some implementations, the transmit signal path of the RF circuitry 2806 can include filter circuitry 2806C and mixer circuitry 2806A. RF circuitry 2806 can also include synthesizer circuitry 2806D for synthesizing a frequency for use by the mixer circuitry 2806A of the receive signal path and the transmit signal path.

[0128] Fig. 29 illustrates a diagram illustrating example interfaces of baseband circuitry that can be employed in accordance with some aspects. As discussed above, the baseband circuitry 2804 of Fig. 28 can comprise processors 2804A-2804E and a memory 2804G utilized by said processors. Each of the processors 2804A-2804E can include a memory interface, 2904A-2904E, respectively, to send / receive data to / from the memory 2804G. The baseband circuitry 2804, or the one or more baseband processors or control logic of the baseband circuitry 2804, may stand alone as the UE 101 or the base station 111 and perform signaling and operation in the meaning as described throughout this disclosure.

[0129] The baseband circuitry 2804 can further include one or more interfaces to communicatively couple to other circuitries / devices, such as a memory interface 2912 (e.g., an interface to send / receive data to / from memory external to the baseband circuitry 2804) , an application circuitry interface 2914 (e.g., an interface to send / receive data to / from the application circuitry 2802 of Fig. 28) , an RF circuitry interface 2916 (e.g., an interface to send / receive data to / from RF circuitry 2806 of Fig. 28) , a wireless hardware connectivity interface 2918 (e.g., an interface to send / receive data to / from Near Field Communication (NFC) components,  components (e.g.,  Low Energy) ,  components, and other communication components) , and a power management interface 2920 (e.g., an interface to send / receive power or control signals to / from the PMC 2812) .

[0130] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine (e.g., a processor (e.g., processor , etc. ) with memory, an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to implementations and examples described.

[0131] Example 1 is a baseband processor configured to, when executing instructions stored in a memory, perform operations comprising: receiving a random access channel (RACH) configuration including a first set of parameters to configure a first set of RACH occasions (ROs) and an additional set of parameters to configure an additional set of ROs, identifying the first set of ROs separate from the additional set of ROs based on a location of the first set of parameters within an information element (IE) structure of the RACH configuration, generating a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs, and performing a RACH procedure based on the validated set of ROs.

[0132] Example 2 comprises any variation of example 1, wherein the location of the first set of parameters within the IE structure comprises the first set of parameters being included in a RACH-ConfigCommon IE in a system information block 1 (SIB1) .

[0133] Example 3 comprises any variation of example 1, wherein the location of the first set of parameters within the IE structure comprises the first set of parameters being included in a same RACH configuration IE as the additional set of parameters.

[0134] Example 4 comprises any variation of example 3, wherein the same RACH configuration IE includes a RACH-ConfigCommon IE or a RACH-ConfigGeneric IE.

[0135] Example 5 comprises any variation of example 3, wherein the operations further comprise: identifying a third set of ROs based on a third set of parameters to configure the third set of ROs being included in a RACH-ConfigCommon IE in a system information block 1 (SIB1) , wherein generating the validated set of ROs is further based on a resource overlap between the third set of Ros and the additional set of ROs.

[0136] Example 6 comprises any variation of example 1, wherein the operations further comprise receiving an indication identifying one or more sets of ROs, wherein identifying the first set of ROs is further based on the indication.

[0137] Example 7 comprises any variation of example 1, wherein the additional set of parameters includes an additional configuration index, an additional frequency division multiplexing (FDM) parameter indicating a number of ROs in the additional set of ROs frequency division multiplexed in a time instance, and an additional frequency start parameter indicating a starting frequency of the additional set of ROs.

[0138] Example 8 comprises any variation of example 7, wherein the first set of parameters and the additional set of parameters are included in a RACH-ConfigGeneric IE, and wherein the RACH-ConfigGeneric IE further includes a synchronization signal block (SSB) per RO parameter indicating a number of SSBs per RO in the additional set of ROs, or wherein the operations further comprise determining a number of SSBs per RO in the additional set of ROs based on an SSB per RO parameter in a RACH-ConfigCommon IE that contains the RACH-ConfigGeneric IE.

[0139] Example 9 comprises any variation of example 7, wherein the RACH configuration includes a RACH-ConfigCommon IE, wherein the first set of parameters are included in a first RACH-ConfigGeneric IE within the RACH-ConfigCommon IE, and wherein the additional set of parameters are included within an additional RACH-ConfigGeneric IE within the RACH-ConfigCommon IE.

[0140] Example 10 comprises any variation of example 9, wherein the RACH-ConfigCommon IE includes a synchronization signal block (SSB) per RO parameter for the first set of ROs, and wherein the RACH-ConfigCommon IE or the additional RACH-ConfigGeneric IE includes an additional SSB per RO parameter for the additional set of ROs.

[0141] Example 11 comprises any variation of example 7, wherein the additional set of parameters further include an additional synchronization signal block (SSB) per RO parameter for the additional set of ROs, and wherein the additional set of parameters are included directly within a RACH-ConfigCommon IE.

[0142] Example 12 is a user equipment (UE) , comprising: radio frequency (RF) circuitry, and a processor configured to execute instructions stored in a memory to cause the UE to: receive a random access channel (RACH) configuration including a first set of parameters to configure a first set of RACH occasions (ROs) and an additional set of parameters to configure an additional set of ROs, identify the first set of ROs based on a location of the first set of parameters within an information element (IE) structure of the RACH configuration, generate a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs, and perform a RACH procedure based on the validated set of ROs.

[0143] Example 13 comprises any variation of example 12, wherein the first set of parameters are included within a first RACH-ConfigCommon IE in a bandwidth part (BWP) uplink common IE, wherein the additional set of parameters are included within an additional RACH-ConfigCommon IE in the BWP uplink common IE, wherein the additional RACH IE contains fewer fields than the first RACH IE.

[0144] Example 14 comprises any variation of example 13, wherein the additional RACH-ConfigCommon IE includes the additional set of parameters directly, or wherein the additional RACH-ConfigCommon IE includes at least one smaller IE containing a subset of the additional set of parameters.

[0145] Example 15 comprises any variation of example 12, wherein the RACH configuration includes a 2-step RACH configuration, and wherein the first set of parameters and the additional set of parameters are included in a 2-step RACH common configuration IE or a 2-step RACH generic configuration IE within the 2-step RACH common configuration IE.

[0146] Example 16 comprises any variation of example 12, wherein the processor further causes the UE to: determine only a 4-step RACH procedure is supported on the additional set of ROs in response to the additional ROs being configured by a RACH-ConfigCommon IE in a system information block 1 (SIB1) or a RACH-ConfigCommon IE within an AdditionalRACH-Config IE, wherein performing the RACH procedure is further based on the determination.

[0147] Example 17 comprises any variation of example 12, wherein the processor further causes the UE to: determine a 2-step RACH procedure is supported on the additional set of ROs in response to the first set of ROs being shared between a 2-step RACH configuration and a 4-step RACH configuration, wherein performing the RACH procedure is further based on the determination.

[0148] Example 18 comprises any variation of example 12, wherein the processor further causes the UE to: determine whether additional features for RACH procedures are supported on the additional set of ROs based on an indication received from a base station, wherein the indication comprises a feature combination list within a RACH-ConfigCommon IE or a separate indication of a subset of features from the feature combination list, wherein performing the RACH procedure is further based on the determination.

[0149] Example 19 is a method, comprising: receiving a random access channel (RACH) configuration including a first set of parameters to configure a first set of RACH occasions (ROs) and an additional set of parameters to configure an additional set of ROs, identifying the first set of ROs based on a location of the first set of parameters within an information element (IE) structure of the RACH configuration, generating a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs, and performing a RACH procedure based on the validated set of ROs.

[0150] Example 20 comprises any variation of example 19, the method further comprising determining whether additional features for 2-step RACH procedures are supported on the additional set of ROs based on one or more of: a predefined rule to support the additional features, a default behavior to not support the additional features, or an indication from a base station on which of the additional features are supported, wherein performing the RACH procedure is further based on the determination.

[0151] Example 21 comprises any variation of example 19, the method further comprising: receiving a physical downlink control channel (PDCCH) order indicating whether the additional ROs are available for a physical random access channel (PRACH) triggered by the PDCCH order, and providing a PRACH communication based on a PRACH resource selection rule, wherein the PRACH resource selection rule includes a default behavior to utilize a resource from the additional set of ROs, selecting a closest resource to the PDCCH order with respect to time, or determining whether to utilize the resource from the additional set of ROs or select the closest resource to the PDCCH order with respect to time based on a 1-bit indication received from a base station.

[0152] Example 22 comprises any variation of example 21, the method further comprising: receiving a physical downlink control channel (PDCCH) in a radio resource control (RRC) IDLE or an RRC INACTIVE state indicating whether the additional ROs are available for a physical random access channel (PRACH) triggered by the PDCCH order, and providing a PRACH communication based on a PRACH resource selection rule, wherein the PRACH resource selection rule includes a default behavior to utilize a resource from the additional set of ROs, selecting a closest resource to the PDCCH with respect to time, or determining whether to utilize the resource from the additional set of ROs or select the closest resource to the PDCCH order with respect to time based on a 1-bit indication received from a base station.

[0153] Example 23 comprises any variation of example 19, the method further comprising: calculating a random access radio network temporary identifier (RA-RNTI) value based on a k offset value received in a system information block (SIB) , and receiving a random access response (RAR) message during a RACH procedure based on the random access radio network temporary identifier (RA-RNTI) .

[0154] Example 24 comprises any variation of example 22, wherein the RA-RNTI value is calculated based on the k offset value in response to a slot of the RAR message containing at least one RO from the first set of ROs and at least one RO from the additional set of ROs, or calculating the RA-RNTI value is irrespective of whether multiple RO configurations exist.

[0155] Example 25 comprises any variation of example 19, the method further comprising: monitoring a physical downlink control channel (PDCCH) search space for response of the additional set of ROs for a random access response (RAR) message during a RACH procedure, wherein the PDCCH search space is configured separately from a PDCCH search space for the first set of ROs.

[0156] Example 26 comprises any variation of example 25, the method further comprising: receiving a PDCCH configuration IE to configure the PDCCH search space for response of the first set of ROs and the PDCCH search space for response of the additional set of ROs, or using a type-1 PDCCH common search space (CSS) in response to the PDCCH search space for the additional set of ROs not being configured by the PDCCH configuration IE.

[0157] Example 27 comprises any variation of example 19, the method further comprising: determining a modified frequency identity (ID) value for an RO based on an initial frequency ID value and a number of ROs from the first set of ROs in a time instance of the RO, and calculating a random access radio network temporary identifier (RA-RNTI) value based on the modified frequency identity (ID) value, wherein determining the modified frequency ID value is in response to ROs from the first and additional sets of ROs overlapping during the time instance of the RO, or irrespective of whether ROs from the first and additional sets of ROs overlap during the time instance of the RO.

[0158] The above description of illustrated examples, implementations, aspects, etc., of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed aspects to the precise forms disclosed. While specific examples, implementations, aspects, etc., are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such examples, implementations, aspects, etc., as those skilled in the relevant art can recognize.

[0159] In this regard, while the disclosed subject matter has been described in connection with various examples, implementations, aspects, etc., and corresponding Figures, where applicable, it is to be understood that other similar aspects can be used or modifications and additions can be made to the disclosed subject matter for performing the same, similar, alternative, or substitute function of the subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single example, implementation, or aspect described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[0160] In particular regard to the various functions performed by the above described components or structures (assemblies, devices, circuits, systems, etc. ) , the terms (including a reference to a “means” ) used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent) , even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

[0161] As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or” . That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B;or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms “including” , “includes” , “having” , “has” , “with” , or variants thereof are used in either the detailed description and the claims, such terms are intended to be inclusive in a manner similar to the term “comprising. ” Additionally, in situations wherein one or more numbered items are discussed (e.g., a “first X” , a “second X” , etc. ) , in general the one or more numbered items can be distinct, or they can be the same, although in some situations the context may indicate that they are distinct or that they are the same.

[0162] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.A baseband processor configured to, when executing instructions stored in a memory, perform operations comprising:receiving a random access channel (RACH) configuration including a first set of parameters to configure a first set of RACH occasions (ROs) and an additional set of parameters to configure an additional set of ROs;identifying the first set of ROs separate from the additional set of ROs based on a location of the first set of parameters within an information element (IE) structure of the RACH configuration;generating a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs; andperforming a RACH procedure based on the validated set of ROs.2.The baseband processor of claim 1, wherein the location of the first set of parameters within the IE structure comprises the first set of parameters being included in a RACH-ConfigCommon IE in a system information block 1 (SIB1) .3.The baseband processor of claim 1, wherein the location of the first set of parameters within the IE structure comprises the first set of parameters being included in a same RACH configuration IE as the additional set of parameters.4.The baseband processor of claim 3, wherein the same RACH configuration IE includes a RACH-ConfigCommon IE or a RACH-ConfigGeneric IE.5.The baseband processor of claim 3, wherein the operations further comprise:identifying a third set of ROs based on a third set of parameters to configure the third set of ROs being included in a RACH-ConfigCommon IE in a system information block 1 (SIB1) ;wherein generating the validated set of ROs is further based on a resource overlap between the third set of Ros and the additional set of ROs.6.The baseband processor of claim 1, wherein the operations further comprise receiving an indication identifying one or more sets of ROs, wherein identifying the first set of ROs is further based on the indication.7.The baseband processor of claim 1, wherein the additional set of parameters includes an additional configuration index, an additional frequency division multiplexing (FDM) parameter indicating a number of ROs in the additional set of ROs frequency division multiplexed in a time instance, and an additional frequency start parameter indicating a starting frequency of the additional set of ROs.8.The baseband processor of claim 7, wherein the first set of parameters and the additional set of parameters are included in a RACH-ConfigGeneric IE; andwherein the RACH-ConfigGeneric IE further includes a synchronization signal block (SSB) per RO parameter indicating a number of SSBs per RO in the additional set of ROs, or wherein the operations further comprise determining a number of SSBs per RO in the additional set of ROs based on an SSB per RO parameter in a RACH-ConfigCommon IE that contains the RACH-ConfigGeneric IE.9.The baseband processor of claim 7, wherein the RACH configuration includes a RACH-ConfigCommon IE, wherein the first set of parameters are included in a first RACH-ConfigGeneric IE within the RACH-ConfigCommon IE, and wherein the additional set of parameters are included within an additional RACH-ConfigGeneric IE within the RACH-ConfigCommon IE.10.The baseband processor of claim 9, wherein the RACH-ConfigCommon IE includes a synchronization signal block (SSB) per RO parameter for the first set of ROs, and wherein the RACH-ConfigCommon IE or the additional RACH-ConfigGeneric IE includes an additional SSB per RO parameter for the additional set of ROs.11.The baseband processor of claim 7, wherein the additional set of parameters further include an additional synchronization signal block (SSB) per RO parameter for the additional set of ROs, and wherein the additional set of parameters are included directly within a RACH-ConfigCommon IE.12.A user equipment (UE) , comprising:radio frequency (RF) circuitry; anda processor configured to execute instructions stored in a memory to cause the UE to:receive a random access channel (RACH) configuration including a first set of parameters to configure a first set of RACH occasions (ROs) and an additional set of parameters to configure an additional set of ROs;identify the first set of ROs based on a location of the first set of parameters within an information element (IE) structure of the RACH configuration;generate a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs; andperform a RACH procedure based on the validated set of ROs.13.The UE of claim 12, wherein the first set of parameters are included within a first RACH-ConfigCommon IE in a bandwidth part (BWP) uplink common IE, wherein the additional set of parameters are included within an additional RACH-ConfigCommon IE in the BWP uplink common IE, wherein the additional RACH-ConfigCommon IE contains fewer fields than the first RACH IE.14.The UE of claim 13, wherein the additional RACH-ConfigCommon IE includes the additional set of parameters directly, or wherein the additional RACH-ConfigCommon IE includes at least one smaller IE containing a subset of the additional set of parameters.15.The UE of claim 12, wherein the RACH configuration includes a 2-step RACH configuration, and wherein the first set of parameters and the additional set of parameters are included in a 2-step RACH common configuration IE or a 2-step RACH generic configuration IE within the 2-step RACH common configuration IE.16.The UE of claim 12, wherein the processor further causes the UE to:determine only a 4-step RACH procedure is supported on the additional set of ROs in response to the additional ROs being configured by a RACH-ConfigCommon IE in a system information block 1 (SIB1) or a RACH-ConfigCommon IE within an AdditionalRACH-Config IE, wherein performing the RACH procedure is further based on the determination.17.The UE of claim 12, wherein the processor further causes the UE to:determine a 2-step RACH procedure is supported on the additional set of ROs in response to the first set of ROs being shared between a 2-step RACH configuration and a 4-step RACH configuration, wherein performing the RACH procedure is further based on the determination.18.The UE of claim 12, wherein the processor further causes the UE to:determine whether additional features for RACH procedures are supported on the additional set of ROs based on an indication received from a base station, wherein the indication comprises a feature combination list within a RACH-ConfigCommon IE or a separate indication of a subset of features from the feature combination list, wherein performing the RACH procedure is further based on the determination.19.A method, comprising:receiving a random access channel (RACH) configuration including a first set of parameters to configure a first set of RACH occasions (ROs) and an additional set of parameters to configure an additional set of ROs;identifying the first set of ROs based on a location of the first set of parameters within an information element (IE) structure of the RACH configuration;generating a validated set of ROs based on a resource overlap between the first set of ROs and the additional set of ROs; andperforming a RACH procedure based on the validated set of ROs.20.The method of claim 19, further comprising determining whether additional features for 2-step RACH procedures are supported on the additional set of ROs based on one or more of:a predefined rule to support the additional features;a default behavior to not support the additional features; oran indication from a base station on which of the additional features are supported;wherein performing the RACH procedure is further based on the determination.21.The method of claim 19, further comprising:receiving a physical downlink control channel (PDCCH) order indicating whether the additional ROs are available for a physical random access channel (PRACH) triggered by the PDCCH order; andproviding a PRACH communication based on a PRACH resource selection rule, wherein the PRACH resource selection rule includes a default behavior to utilize a resource from the additional set of ROs, selecting a closest resource to the PDCCH order with respect to time, or determining whether to utilize the resource from the additional set of ROs or select the closest resource to the PDCCH order with respect to time based on a 1-bit indication received from a base station.22.The method of claim 19, further comprising:receiving a physical downlink control channel (PDCCH) in a radio resource control (RRC) IDLE or an RRC INACTIVE state indicating whether the additional ROs are available for a physical random access channel (PRACH) triggered by the PDCCH order; andproviding a PRACH communication based on a PRACH resource selection rule, wherein the PRACH resource selection rule includes a default behavior to utilize a resource from the additional set of ROs, selecting a closest resource to the PDCCH with respect to time, or determining whether to utilize the resource from the additional set of ROs or select the closest resource to the PDCCH order with respect to time based on a 1-bit indication received from a base station.23.The method of claim 19, further comprising:calculating a random access radio network temporary identifier (RA-RNTI) value based on a k offset value received in a system information block (SIB) ; andreceiving a random access response (RAR) message during a RACH procedure based on the random access radio network temporary identifier (RA-RNTI) .24.The method of claim 23, wherein the RA-RNTI value is calculated based on the k offset value in response to a slot of the RAR message containing at least one RO from the first set of ROs and at least one RO from the additional set of ROs, or calculating the RA-RNTI value is irrespective of whether multiple RO configurations exist.25.The method of claim 19, further comprising:monitoring a physical downlink control channel (PDCCH) search space for response of the additional set of ROs for a random access response (RAR) message during a RACH procedure, wherein the PDCCH search space is configured separately from a PDCCH search space for the first set of ROs.26.The method of 25, further comprising:receiving a PDCCH configuration IE to configure the PDCCH search space for response of the first set of ROs and the PDCCH search space for response of the additional set of ROs; orusing a type-1 PDCCH common search space (CSS) in response to the PDCCH search space for the additional set of ROs not being configured by the PDCCH configuration IE.27.The method of claim 19, further comprising:determining a modified frequency identity (ID) value for an RO based on an initial frequency ID value and a number of ROs from the first set of ROs in a time instance of the RO; andcalculating a random access radio network temporary identifier (RA-RNTI) value based on the modified frequency identity (ID) value;wherein determining the modified frequency ID value is in response to ROs from the first and additional sets of ROs overlapping during the time instance of the RO, or irrespective of whether ROs from the first and additional sets of ROs overlap during the time instance of the RO.

Images