Method and apparatus for determining RACH occasions for an ra procedure

Abstract

A method performed by a UE for determining random access channel (RACH) occasions for a random access (RA) procedure is provided. The method receives, from a base station (BS), downlink control information (DCI) including a first field that indicates a first RACH occasion type or a second RACH occasion type. The method determines, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type. The method determines one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type.

Description

METHOD AND APPARATUS FOR DETERMINING RACH OCCASIONS FOR AN RA PROCEDURE

[0001] The present disclosure is related to wireless communication and, more specifically, to a User Equipment (UE), Base Station (BS), and method for determining random access channel (RACH) occasions for a random access (RA) procedure in the wireless communication networks.

[0002] Various efforts have been made to improve different aspects of wireless communication for the cellular wireless communication systems, such as the 5thGeneration (5G) New Radio (NR), by improving data rate, latency, reliability, and mobility. The 5G NR system is designed to provide flexibility and configurability to optimize network services and types, accommodating various use cases, such as enhanced Mobile Broadband (eMBB), massive Machine-Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC). As the demand for radio access continues to grow, however, there exists a need for further improvements in the next-generation wireless communication systems, such as improvements in a beam management procedure.

[0003] The present disclosure is related to a UE, a BS, and a method for determining random access channel (RACH) occasions for a random access (RA) procedure in the wireless communication networks.

[0004] In a first aspect of the present disclosure, a UE for determining random access channel (RACH) occasions for a random access (RA) procedure is provided. The UE includes at least one processor and at least one non-transitory computer-readable medium that is coupled to the at least one processor and that stores one or more computer-executable instructions. The computer-executable instructions, when executed by the at least one processor, cause the UE to: receive, from a base station (BS), downlink control information (DCI) including a first field that indicates a first RACH occasion type or a second RACH occasion type; determine, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type; and determine one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type.

[0005] In some implementations of the first aspect, the DCI further includes a mask index field, and the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: determine the one or more RACH occasions further based on the mask index field.

[0006] In some implementations of the first aspect, the mask index field indicates that the one or more RACH occasions associated with determined RACH occasion type are used for a physical random access channel (PRACH) transmission.

[0007] In some implementations of the first aspect, the DCI is a DCI format 1_0.

[0008] In a second aspect of the present disclosure, a method performed by a user equipment (UE) for determining random access channel (RACH) occasions for a random access (RA) procedure is provided. The method includes: receiving, from a base station (BS), downlink control information (DCI) including a first field that indicates a first RACH occasion type or a second RACH occasion type; determining, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type; and determining one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type.

[0009] In a third aspect of the present application, a BS for determining random access channel (RACH) occasions for a random access (RA) procedure is provided. The BS includes at least one processor and at least one non-transitory computer-readable medium that is coupled to the at least one processor and that stores one or more computer-executable instructions. The computer-executable instructions, when executed by the at least one processor, cause the BS to: transmit, to a user equipment (UE), downlink control information (DCI) including a first field that indicates a first RACH occasion type or a second RACH occasion type, where the DCI causes the UE to: determine, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type; and determine one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type.

[0010] Aspects of the present disclosure are best understood from the following detailed disclosure when read with the accompanying drawings. Various features are not drawn to scale. Dimensions of various features may be arbitrarily increased or reduced for clarity of discussion.

[0011] FIG. 1 is a diagram illustrating an example of different RO type allocation and configuration, according to an example implementation of the present disclosure.

[0012] FIG. 2 is a flowchart illustrating an RA procedure under multiple RACH configurations, according to an example implementation of the present disclosure.

[0013] FIG. 3 is a flowchart illustrating an RO determination procedure under multiple RACH configurations, according to an example implementation of the present disclosure.

[0014] FIG. 4 is a flowchart illustrating a method / process performed by a UE for determining random access channel (RACH) occasions for a random access (RA) procedure, according to an example implementation of the present disclosure.

[0015] FIG. 5 is a block diagram illustrating a node for wireless communication in accordance with various aspects of the present disclosure.

[0016] The following contains specific information related to implementations of the present disclosure. The drawings and their accompanying detailed disclosure are merely directed to implementations. However, the present disclosure is not limited to these implementations. Other variations and implementations of the present disclosure will be obvious to those skilled in the art.

[0017] Unless noted otherwise, like or corresponding elements among the drawings may be indicated by like or corresponding reference numerals. Moreover, the drawings and illustrations in the present disclosure are generally not to scale and are not intended to correspond to actual relative dimensions.

[0018] For the purposes of consistency and ease of understanding, like features may be identified (although, in some examples, not illustrated) by the same numerals in the drawings. However, the features in different implementations may be different in other respects and may not be narrowly confined to what is illustrated in the drawings.

[0019] References to “one implementation,” “an implementation,” “example implementation,” “various implementations,” “some implementations,” “implementations of the present application,” etc., may indicate that the implementation(s) of the present application so described may include a particular feature, structure, or characteristic, but not every possible implementation of the present application necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase “In some implementations,” or “in an example implementation,” “an implementation,” do not necessarily refer to the same implementation, although they may. Moreover, any use of phrases like “implementations” in connection with “the present application” are never meant to characterize that all implementations of the present application must include the particular feature, structure, or characteristic, and should instead be understood to mean “at least some implementations of the present application” includes the stated particular feature, structure, or characteristic. The term “coupled” is defined as connected, whether directly or indirectly through intervening components, and is not necessarily limited to physical connections. The term “comprising,” when utilized, means “including, but not necessarily limited to”; it specifically indicates open-ended inclusion or membership in the so-described combination, group, series, and the equivalent.

[0020] The expression “at least one of A, B and C” or “at least one of the following: A, B and C” means “only A, or only B, or only C, or any combination of A, B and C.” The terms “system” and “network” may be used interchangeably. The term “and / or” is only an association relationship for describing associated objects and represents that three relationships may exist such that A and / or B may indicate that A exists alone, A and B exist at the same time, or B exists alone. The character “ / ” generally represents that the associated objects are in an “or” relationship.

[0021] For the purposes of explanation and non-limitation, specific details, such as functional entities, techniques, protocols, and standards, are set forth for providing an understanding of the disclosed technology. In other examples, detailed disclosure of well-known methods, technologies, systems, and architectures are omitted so as not to obscure the present disclosure with unnecessary details.

[0022] Persons skilled in the art will immediately recognize that any network function(s) or algorithm(s) disclosed may be implemented by hardware, software, or a combination of software and hardware. Disclosed functions may correspond to modules which may be software, hardware, firmware, or any combination thereof.

[0023] A software implementation may include computer executable instructions stored on a computer-readable medium, such as memory or other type of storage devices. One or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and perform the disclosed network function(s) or algorithm(s).

[0024] The microprocessors or general-purpose computers may include Application-Specific Integrated Circuits (ASICs), programmable logic arrays, and / or one or more Digital Signal Processor (DSPs). Although some of the disclosed implementations are oriented to software installed and executing on computer hardware, alternative implementations implemented as firmware, as hardware, or as a combination of hardware and software are well within the scope of the present disclosure. The computer-readable medium includes but is not limited to Random Access Memory (RAM), Read Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, Compact Disc Read-Only Memory (CD-ROM), magnetic cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions.

[0025] A radio communication network architecture such as a Long-Term Evolution (LTE) system, an LTE-Advanced (LTE-A) system, an LTE-Advanced Pro system, or a 5G NR Radio Access Network (RAN) typically includes at least one base station (BS), at least one UE, and one or more optional network elements that provide connection within a network. The UE communicates with the network such as a Core Network (CN), an Evolved Packet Core (EPC) network, an Evolved Universal Terrestrial RAN (E-UTRAN), a 5G Core (5GC), a 6G Core (6GC), or an internet via a RAN established by one or more BSs.

[0026] A UE may include, but is not limited to, a mobile station, a mobile terminal or device, or a user communication radio terminal. The UE may be a portable radio equipment that includes, but is not limited to, a mobile phone, a tablet, a wearable device, a sensor, a vehicle, or a Personal Digital Assistant (PDA) with wireless communication capability. The UE is configured to receive and transmit signals over an air interface to one or more cells in a RAN.

[0027] The BS may be configured to provide communication services according to at least a Radio Access Technology (RAT) such as Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile communications (GSM) that is often referred to as 2G, GSM Enhanced Data rates for GSM Evolution (EDGE) RAN (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunication System (UMTS) that is often referred to as 3G based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), LTE, LTE-A, evolved LTE (eLTE) that is LTE connected to 5GC, NR (often referred to as 5G), and / or LTE-A Pro. However, the scope of the present disclosure is not limited to these protocols.

[0028] The BS may include, but is not limited to, a node B (NB) in the UMTS, an evolved node B (eNB) in LTE or LTE-A, a radio network controller (RNC) in UMTS, a BS controller (BSC) in the GSM / GERAN, an ng-eNB in an Evolved Universal Terrestrial Radio Access (E-UTRA) BS in connection with 5GC, a next generation Node B (gNB) in the 5G-RAN, or any other apparatus capable of controlling radio communication and managing radio resources within a cell. The BS may serve one or more UEs via a radio interface. Although the gNB is used as an example in some implementations within the present disclosure, it should be noted that the disclosed implementations may also be applied to other types of base stations.

[0029] The BS may be operable to provide radio coverage to a specific geographical area using multiple cells forming the RAN. The BS may support the operations of the cells. Each cell may be operable to provide services to at least one UE within its radio coverage.

[0030] Each cell (may often referred to as a serving cell) may provide services to one or more UEs within the cell’s radio coverage, such that each cell schedules the DL (and optionally UL resources) to at least one UE within its radio coverage for DL (and optionally UL packet transmissions from the UE). The BS may communicate with one or more UEs in the radio communication system via the cells.

[0031] A cell may allocate sidelink (SL) resources for supporting the Proximity Services (ProSe) or Vehicle to Everything (V2X) services. Each cell may have overlapped coverage areas with other cells.

[0032] In Multi-RAT Dual Connectivity (MR-DC) cases, the primary cell of a Master Cell Group (MCG) or a Secondary Cell Group (SCG) may be referred to as a Special Cell (SpCell). A Primary Cell (PCell) may include the SpCell of an MCG. A Primary SCG Cell (PSCell) may include the SpCell of an SCG. MCG may include a group of serving cells associated with the Master Node (MN), including the SpCell and optionally one or more Secondary Cells (SCells). An SCG may include a group of serving cells associated with the Secondary Node (SN), including the SpCell and optionally one or more SCells.

[0033] As discussed above, the frame structure for NR may support flexible configurations for accommodating various next generation (e.g., 5G) communication requirements, such as Enhanced Mobile Broadband (eMBB), Massive Machine Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC), while fulfilling high reliability, high data rate, and low latency requirements. The Orthogonal Frequency-Division Multiplexing (OFDM) technology in the 3GPP may serve as a baseline for an NR waveform. The scalable OFDM numerology, such as adaptive sub-carrier spacing, channel bandwidth, and Cyclic Prefix (CP), may also be used.

[0034] Two coding schemes may be considered for NR, specifically, Low-Density Parity-Check (LDPC) code and Polar Code. The coding scheme adaption may be configured based on channel conditions and / or service applications.

[0035] At least the DL transmission data, a guard period, and UL transmission data should be included in a transmission time interval (TTI) of a single NR frame. The respective portions of the DL transmission data, the guard period, and the UL transmission data should also be configurable based on, for example, the network dynamics of NR. SL resources may also be provided in an NR frame to support ProSe services or V2X services.

[0036] Any two or more than two of the following paragraphs, (sub)-bullets, points, actions, behaviors, terms, or claims described in the present disclosure may be combined logically, reasonably, and properly to form a specific method.

[0037] Any sentence, paragraph, (sub)-bullet, point, action, behaviors, terms, or claims described in the present disclosure may be implemented independently and separately to form a specific method.

[0038] Dependency, e.g., “based on”, “more specifically”, “preferably”, “in one embodiment”, “in some implementations”, etc., in the present disclosure is just one possible example which would not restrict the specific method.

[0039] In some implementations, all the designs / embodiment / implementations introduced within this disclosure are not limited to be applied for dealing with the problems discussed within this disclosure. For example, the described embodiments may be applied to solve other problems that exist in the RAN of wireless communication systems. In some implementations, all of the numbers listed within the designs / embodiment / implementations introduced within this disclosure are just examples and for illustration, for example, of how the described methods are executed.

[0040] The term “A and / or B” within the present disclosure means “A”, “B”, or “A and B”. The term “A and / or B and / or C” within the present disclosure means “A”, “B”, “C”, “A and B”, “A and C”, “B and C”, or “A and B and C”. The term “A / B” within the present disclosure means “A” or “B”.

[0041] In the 3GPP Rel-19, the objective of the Network Energy Saving (NES) work item description (WID) may specify the adaptation of a common signal or channel transmission. The adaptation may occur for the physical random access channel (PRACH) in the time domain, where the gNB may adjust the PRACH occasion (RO) in the time domain to reduce management of the RA procedure, thereby conserving network power consumption. Furthermore, the adaptation may consider cell loading to achieve a balance between the network power consumption and UE access latency. A fixed number of ROs, along with additional ROs, may be configured to meet this objective. For example, when cell loading is low, the gNB may configure a fixed number of ROs and enter a network power saving mode. Conversely, when cell loading is high, the gNB may configure additional ROs in different time domains to distribute access attempts and enter a network normal operation mode.

[0042] In some implementations, an additional RO configuration may be provided for the Sub-Band Fully Duplexing (SBFD) WID. The UE aware of SBFD (e.g., the SBFD-aware UE) may support simultaneous DL reception and UL transmission within a specific sub-band. The SBFD-aware UE may initiate the RA procedure using the SBFD RO to reduce access latency, with the SBFD RO provided in a separate configuration. In contrast, the legacy UE, not aware of SBFD (e.g., not SBFD-aware UE), may only be configured with a common PRACH configuration, and the corresponding RO may not be valid in the SBFD sub-band.

[0043] In addition to access latency, coverage extension may be a factor in designing the RA procedure. In the 3GPP Rel-17 and Rel-18, enhancements to the RA procedure for extending cell coverage were discussed, and the repetition of Msg3 and Msg 1 (e.g., preamble) may be respectively specified. However, when required, repetition of Msg3 or Msg1 may increase operations of the gNB, resulting in higher power consumption.

[0044] As a consequence, how to jointly consider the aforementioned designs to meet various requirements may be unclear. Specifically, whether to apply the same or different RA procedures under different RACH configurations to fulfill requirements of different vendors may require further consideration.

[0045] Followed by latest 3GPP discussions, to solve the issued indicated above, there are agreements on SBFD feature with additional PRACH configuration: (a) For SBFD-aware UEs and PRACH mask indication for Contention-Free Random Access (CFRA) triggered by the PDCCH order, it may be required to discuss whether / how to indicate / determine that additional-RO only, legacy-RO only, or both is used. (b) Upon initiation of the Contention-Based Random Access (CBRA) procedure for a SBFD-aware UE, the UE may select one type of ROs between legacy ROs and additional ROs based on certain specified / configured conditions or prioritizations, if no additional indication is received from the network. (c) For the PRACH transmission re-attempt in one RA procedure, after certain number of times of RACH attempt in SBFD RACH occasions, the UE may be allowed to switch to legacy RACH occasions. The RACH attempt may correspond to Random Access Preamble transmission attempt.

[0046] From the perspective of UE capabilities, the following four categories of UEs (a)-(d) may be defined.

[0047] (a) Legacy UE (UE #L): The legacy UE, referred to as UE#L, may comply with the 3GPP Rel-15, Rel-16, Rel-17, Rel-18, or Rel-19 specifications for LTE or NR and may not support the Rel-19 NES or SBFD features. The Legacy UE (UE #L) may support repetition mechanisms for Msg1 and Msg3 and may only perform the RA procedure based on the basic RO.

[0048] (b) NES-capable UE (UE #N): The NES-capable UE, referred to as UE#N, may support PRACH adaptation based on additional PRACH resources and may utilize the additional RO for the corresponding RA procedure. The NES-capable UE (UE #N) may also support repetition of Msg1 and / or Msg3 during the RA procedure based on the configuration. For example, the NES-capable UE (UE#N) may be a Rel-19 UE supporting the NES feature.

[0049] (c) SBFD-aware UE (UE #S): The SBFD-aware UE, referred to as UE#S, may perform transmission and reception on SBFD resources and may perform the RA procedure based on the SBFD RO when the SBFD RO is configured by the serving RAN. The SBFD-aware UE (UE#S) may also support repetition of Msg1 and / or Msg3 during the RA procedure based on the configuration. For example, the SBFD-aware UE (UE#S) may be a Rel-19 UE supporting the SBFD feature.

[0050] (d) Feature Combination UE (UE #F): The Feature-combination UE, referred to as UE#F, may support both the NES and SBFD features and may perform the RA procedure based on all ROs, including the SBFD RO, the additional RO, and the basic RO. The feature-combination UE (UE#F) may also support repetition of Msg1 and / or Msg3 during the RA procedure based on the configuration.

[0051] From the perspective of resource configuration and allocation by the gNB, the following three types of ROs (a)-(c) may be configured through separate RACH configurations. FIG. 1 is a diagram illustrating an example of different RO type allocation and configuration, according to an example implementation of the present disclosure. In FIG. 1, three RACH configurations may be defined, each with different PRACH parameter settings.

[0052] (a) Basic RO (RO#B): The basic RO, referred to as RO#B, may be primarily configured via the RACH-ConfigCommon IE in SIB1 (e.g., the RACH configuration #1 in FIG. 1). Upon receiving the configuration (e.g., the RACH configuration #1), the UE may obtain information including a number of ROs per SSB, a number of CBRA preambles, a preamble format, a time and frequency domain resource configuration, a power ramping setting, and parameters for an RA procedure. Specifically, the PRACH-ConfigurationIndex IE may determine the preamble format, slot number, starting symbol, number of ROs within a PRACH slot, and duration, enabling the UE to identify corresponding entries based on a given index and trigger the RA procedure based on the selected basic RO (RO#B).

[0053] (b) Additional RO (RO#A): The additional RO, referred to as RO#A, may be activated or deactivated (e.g., On / Off) based on network power saving objectives. A separate RACH configuration (e.g., the RACH configuration #2 in FIG. 1) different from the RACH-ConfigCommon IE, may be signaled to the UE. The additional RO may be configured for both connected UEs and idle / inactive UEs via a broadcast message or a dedicated message. Unlike the basic RO (RO#B), the validity / availability of the additional RO (RO#A) may require additional control management to support adaptation, and the availability of the additional RO (RO#A) may not be persistent.

[0054] (c) SBFD RO (RO#S): The SBFD RO, referred to as RO#S, may be persistently available only in specific time domains, and the allocation may be reconfigured when a frame structure, such as that defined by the tdd-UL-DL-ConfigurationCommon IE, changes. Only the SBFD-aware UE (UE#S) may treat the configuration (e.g., the RACH configuration #3 in FIG. 1) as valid and perform the RA procedure based on the SBFD RO (RO#S). Both connected UEs and idle / inactive UEs may receive the RACH configuration #3, but the corresponding RA trigger may be limited to specific procedures, such as BFR or uplink resource requests (e.g., scheduling requests). The RACH configuration #3 may be provided via a dedicated message. For idle / inactive UEs, the dedicated message may be a paging message scheduled by group-common DCI.

[0055] Considering the UE categories and RO allocations, the applicable scenarios may be provided in Table 1. Table 1 below illustrates the validity of RO types for different UE categories in idle / inactive and connected states, according to an example implementation of the present disclosure.

[0056] In various scenarios, different categories of UE may have access to different valid ROs with corresponding configurations within a single serving cell. To initiate an RA procedure, a unified process may be executed, which may include (a) initialization of the RA procedure, (b) selection of RA resources, (c) transmission of an RA preamble, (d) reception of a RAR, (e) contention resolution, and (f) completion. However, when multiple RACH configurations specifying different RO types are provided, the handling of the RA procedure under varying RO validity conditions may remain unspecified. The RA procedure may need to be performed multiple times, for instance, due to a failure in RAR reception or contention resolution and / or Msg1 or Msg3 transmission is indicated to repeat the transmission. The mechanism to address a situation where a specific RO becomes invalid or inapplicable during multiple transmissions may require further specified.

[0057] Specifically, if CFRA is initiated, how to indicate which kinds of RO (e.g., RO#B, RO#A, RO#S) be used for contention free transmission via the DCI format and how to further consider the PRACH mask during the RO type selection should be clarified. On the other hand, if CBRA is initiated based on one of RO types, how to handle the fallback subject to failure of preamble transmission and the interaction with the RO type selection shall be clarified as well.

[0058] A challenge in implementing a unified RA procedure under multiple RACH configurations with corresponding ROs may involve determining a RO set and the composition thereof. The determination may depend on the purpose of the RA procedure and the type of RA applied. Different RA purposes or types may be accomplished with different parameter settings provided through the RACH configurations. FIG. 2 is a flowchart illustrating an RA procedure under multiple RACH configurations, according to an example implementation of the present disclosure. The steps / actions shown in FIG. 2 should not be construed as necessarily order dependent. The order in which the process is described is not intended to be construed as a limitation. Moreover, some of the actions shown in FIG. 2 may be omitted in some implementations and one or more actions shown in FIG. 2 may be combined.

[0059] In the action 202, the UE may receive information regarding the basic RO (RO#B), the additional RO (RO#A), and the SBFD RO (RO#S) configuration through system information or a (UE-specific or group-common) dedicated message, and the UE may identify supported ROs based on the UE capability. Based on the respective configurations, the gNB may provide RA parameters applicable to the configured ROs.

[0060] In some implementations, when no corresponding parameters are provided in the RO#A configuration or the RO#S configuration, the UE may apply the same parameter settings as those for the RO#B and determine that the RO is valid. In some implementations, when no corresponding parameters are provided in the RO#A configuration or the RO#S configuration, the UE may apply the stored parameter settings from previous RACH configurations for the corresponding RO type and determine that the RO is valid. In some implementations, when no corresponding parameters are provided in the RO#A configuration or the RO#S configuration, the UE may assume the RO to be invalid for associated procedures and skip the RO during initialization of the RA procedure. The associated procedures may include an IAB-MT RA procedure (e.g., where the prach-ConfigurationPeriodScaling-IAB IE, the prach-ConfigurationFrameOffset-IAB IE, and the prach-ConfigurationSOffset-IAB IE are expected to be configured), a 2-step RA procedure (e.g., where parameters related to the 2-step RA are expected to be configured), and other procedures which are specified to provide additional parameters to support its operation in the 3GPP TS. If the fallback occurs during on-going RA procedure, the UE may apply associated PRACH parameters on the new selected RO type and reset the associated parameters. In case the new selected RO type hasn’t been provided with PRACH parameters in its configuration, the UE may either (1) not require resetting the parameters or (2) reset the parameters with the initial value which is configured for the RO#B.

[0061] In some implementations, RA parameters initialized for the corresponding RO may be updated based on subsequent steps. For example, the preambleReceivedTargetPower IE may be provided via additional RACH configuration and applied for the RO#A. However, the setting may be updated when the RO#A is grouped with the RO#S into a RO set, and a second preambleReceivedTargetPower IE is applied. A group RA parameter setting may be introduced for the RO set when different RO types are grouped together. The group RA parameter may be included in the RACH configuration for the RO#A and the RO#S, where the RACH configuration may correspond to respective configuration messages for the RO#A and the RO#S.

[0062] In some implementations, the group RA information IE may be included in the RACH configuration for the RO#B. The UE may reinitialize the RA parameters using the group RA parameter when the associated ROs are grouped into a specific set. For instance, the preambleReceivedTargetPower IE and the Group-preambleReceivedTargetPower IE may be provided in the RO#A configuration. When the RO#A is grouped with the RO#S under a specific condition, the value of the Group-preambleReceivedTargetPower IE may be reinitialized for this RO; otherwise, the value of the preambleReceivedTargetPower IE may be applied. The specific condition may be pre-defined.

[0063] In some implementations, the new IE (e.g., Group RA IE) with a Boolean value of “True” or “False,” may be provided in the RACH configuration. When the value is set to “True,” the UE may reinitialize the RA parameters by applying settings from other RACH configurations when the RO is grouped with another RO type. Otherwise, the UE may use the configured parameter value for initialization, even when the RO is grouped with another RO type. In some implementations, the UE may continue using the same parameters if all ROs in the RO set belong to the same type.

[0064] In the action 204, the RA type may be applied for the event and RA procedure based on triggering events. The triggering events may include a handover (reconfiguration with sync), BFR, SI request, on-demand SSB or SIB1 request, PDCCH order, scheduling request failure, TA acquisition, early uplink synchronization with LTM, and / or new events (e.g., specific to NES or SBFD). The RA type may include a 4-step RA, a 2-step RA, CBRA, and / or CFRA.

[0065] Based on the configurations of the RO#A and the RO#S, the gNB may mask the associated RO for a specific triggering event and / or RA type using at least one new mask index IE included in the RACH configurations. The restriction may be applied during RA initialization and subsequent RO set initialization.

[0066] The mask indication may be applied for a 4-step RA, a 2-step RA, CBRA, and / or CFRA. Moreover, if the NW indicates the PRACH Mask Index in DCI (e.g., as PDCCH order) for CFRA, the DCI indication may overwrite the configuration in the RRC message. For example, the PRACH Mask index may be configured by either RRC message or DCI format. The RRC configuration may be mainly used for CBRA and DCI may be mainly used for CFRA. If the RRC configuration configures the PRACH Mask index=0 (e.g., all RO occasions are allowed) but the DCI indicates the PRACH Mask index=1 (e.g., RO occasion index1), the UE may apply the PRACH Mask index=1 and ignores / releases the PRACH Mask index configured by the RRC configuration. Otherwise, the UE may apply the RRC configuration if the PRACH Mask index information is absent in the DCI.

[0067] The UE may verify whether the configured RO#A and RO#S are valid based on the UE capability (e.g., as shown in Table 1), and store the corresponding valid configuration. When a triggering event is identified, the UE may check whether the associated mask is enabled based on the stored information. If the result indicates validity and no restriction (e.g., the mask IE associated with the triggering event is present with a value of “False”), the UE may initialize specific variables for the corresponding event and determine the RO configuration as a candidate resource for the RO set. Otherwise, the UE may skip initialization for the RACH configuration.

[0068] Regarding RA type determination, when no mask is indicated for the RA type in the RACH configuration, the RO#A and the RO#S may remain in the candidate resource set after validation and restriction checks for the triggering event; otherwise (e.g., the mask IE is present and set to “True” for the corresponding RACH configuration), the associated RO#A and RO#S may be excluded from consideration as candidate ROs for the indicated RA type, even if the validation and restriction checks are met.

[0069] In some implementations, when the RA procedure is initiated for BFR, the gNB may configure the BFR-mask IE with a value of “True” in the RO#S configuration. Although the SBFD-aware UE (UE#S) may treat the configuration as valid, the UE may restrict the RO#S from the candidate RA resources. In some implementations, when the RA procedure is initiated for SCell BFR, the gNB may configure the BFR-mask IE with a value of “False” and the 2-step RA-mask IE with a value of “True” in the RO#S configuration. The SBFD-aware UE (UE#S) may select the RO#S as a candidate resource for the purpose but may only use the resource during a 4-step RA procedure, while the RO#S may be removed from the candidate resource set if a 2-step RA is used. In some implementations, when the RA procedure is initiated for SCell BFR, the gNB may configure the BFR-mask IE with a value of “False” and the 2-step RA-mask IE with a value of “False” in the RO#S configuration. The SBFD-aware (UE#S) UE may select the RO#S as a candidate resource for both 2-step RA and 4-step RA procedures for the corresponding trigger.

[0070] Under CFRA behavior, the network may trigger a PDCCH order by sending a DCI Format 1_0 on the SSB beam which the UE selects. The PDCCH order may be sent via the DCI Format 1_0 with CRC scrambled by C-RNTI, including the SSB index, ra-PreambleIndex and PRACH Mask Index. The field of PRACH Mask index may include 4 bits. If the value of the “Random Access Preamble index” is not all zeros, this field may indicate the RACH occasion associated with the SS / PBCH indicated by “SS / PBCH index” for the PRACH transmission. The PRACH Mask index may be applicable if the preamble index bit is not ‘0’ (e.g., a dedicated Preamble index has been assigned by the network to the UE).

[0071] Table 2 below illustrates the PRACH Mask index value and corresponding allowed PRACH occasions of SSB, according to an example implementation of the present disclosure. Under RO#B, RO#A, and RO#S configuration, it may need to investigate how to apply the PRACH Mask index as indicated in the DCI and which corresponding RO be dedicated use.

[0072] In some implementations, the separated PRACH mask index (field) may be provided in the DCI, and different RACH configuration may be associated with a respective PRACH mask index (field). The UE may apply the corresponding mask setting on the configured ROs, and the order of PRACH Mask Index may be determined by a default rule or configured by the NW. The default rule may include a fixed order, the reception of configuration order, and / or the associated PRACH configuration index.

[0073] If there is no RACH configuration configured for the RO#A and RO#S, the NW may not append the corresponding PRACH Mask index in the DCI format 1_0 (e.g., it may mean that the size of DCI format is variable) or the NW may append all “0” (e.g., to fix the size of DCI format). If an RRC parameter disables the RACH configuration configured for the RO#A and RO#S and / or the RRC parameter disables the SBFD function, the NW may not append the corresponding PRACH Mask index in the DCI format 1_0 or the NW may append all “0” or a specific value. If the NW transmits a MAC CE disabling the RACH configuration configured for the RO#A and RO#S, the NW may not append the corresponding PRACH Mask in the DCI format 1_0 or the NW may append all “0” or a specific value.

[0074] In some implementations, a unified PRACH Mask index may be indicated in the DCI format 1_0, and the UE may apply the same indicated occasion for the configured ROs. Specifically, the index table may be the same regardless of other RACH configurations (e.g., for either RO#A or RO#S) are configured. In some implementations, a unified PRACH Mask index may be indicated in the DCI format 1_0 but the applied table may be different based on the configuration. For example, the original table may be applied while the common RACH configuration is configured. While the RACH configuration of RO#S is configured, a new table #1 may be applied and each entry in the table may be given a new occasion index for the RO#B and RO#S, and the UE may follow the indicated occasion index for the corresponding RO#B or RO#S to decide the allowed ROs.

[0075] If there is a RACH configuration for the RO#A and RO#S, the PRACH Mask index indicated in the DCI format 1_0 may be based on the new table (e.g., new table#1). If an RRC parameter enables the RACH configuration configured for the RO#A and RO#S and / or the RRC parameter enables the SBFD function, the PRACH Mask index indicated in the DCI format 1_0 may be based on the new table (e.g., new table#1).

[0076] In some implementations, a unified PRACH Mask index and a unified table may be used for all RACH configurations, and the index #0-10 may be applied for the RO#B. The reserved index (11-15) may be defined and applied for specific ROs. While the UE receives the DCI format 1_0 with PRACH Mask index 1-10, the UE may determine that the CFRA is performed on the RO#B and apply the allowed PRACH occasion on the RO#B. While the UE receives the DCI format 1_0 other than PRACH Mask index 1-10, the UE may determine that the CFRA is performed on the RO#S, RO#A, or both based on the index configuration.

[0077] In some implementations, a new DCI information field may be introduced to indicate whether the given PRACH Mask Index is applicable for which RO types. For example, an IE called RO type may be introduced, where it may be 2-bit information. The value “00” may indicate that the PRACH Mask Index is only applicable for the RO#B, the value “01” may indicate that the PRACH Mask Index is applicable for the RO#B and RO#S, the value “10” may indicate that the PRACH Mask Index is applicable for the RO#B and RO#A, and the value “11” may indicate that the PRACH Mask Index is applicable for the RO#B, RO#A and RO#S. In some implementations, the RO#A or RO#S may not be applied for the CFRA by default, so only one bit may be required for this new IE. The value “0” may indicate that the PRACH Mask Index is applicable for the RO#B, and the value “1” may indicate that the PRACH Mask Index is applicable for both configurations.

[0078] For example, if (i) a UE is configured with the RACH configuration for the RO#A and / or RO#S, (ii) the RACH configuration for the RO#A and / or RO#S is enabled by the RRC and / or activated by the MAC CE, and / or (iii) the SBFD function is enabled by the RRC, the DCI format 1_0 (e.g., PDCCH order) may include a DCI field indicating which RO type is applied for the RA procedure initiated by that PDCCH order. The DCI field size may be 2 bits. The value “00” may indicate that the RO type is the RO#B (only) and the PRACH Mask Index may be applicable for the RO#B, the value “01” may indicate that the RO type are both RO#B and RO#S and the PRACH Mask Index may be applicable for the RO#B and RO#S, the value “10” may indicate that the RO type are both RO#B and RO#A and the PRACH Mask Index may be applicable for the RO#B and RO#A, and the value “11” may indicate that the RO type are the RO#B,RO#A and RO#S, and the PRACH Mask Index may be applicable for the RO#B, RO#A and RO#S. In some implementations, the RO#A or RO#S may not be applied for the CFRA by default, so the DCI format 1_0 (e.g., PDCCH order) may include a DCI field indicating whether the RO#A and RO#S are applied for the CFRA. The DCI field size may be 1 bit. The value “0” may indicate that the RO#B is applied for the CFRA and PRACH Mask Index is applicable for the RO#B, and the value “1” may indicate that the RO#A and RO#S are applied for the CFRA and PRACH Mask Index is applicable for the RO#A and RO#S.

[0079] In some implementations, the gNB may reconfigure the RACH configuration (e.g., the additional RACH configuration is released, and the RO#A becomes invalid) and the UE may receive the configuration during the action 204. The following alternatives 1-6 are proposed to react with this condition.

[0080] Alternative 1: While receiving reconfiguration for the RO#A and RO#S, the UE may re-perform the action 204 again (e.g., to flush the current initialization and candidate resource set determination) via new configurations.

[0081] Alternative 2: The UE may remove all selected RO#A and RO#S regardless of the setting with respect to the reconfiguration. This may mean that the UE may fall back to use the RO#B even if there are potential candidate resources configured by the reconfiguration.

[0082] Alternative 3: The UE may ignore the reconfiguration until the initiated RA procedure is completed or is recognized as RA fail.

[0083] Alternative 4: The UE may recognize the RA fails if the UE receives the reconfiguration of the RACH configuration during a RA procedure. In some implementations, the RRC layer / entity (e.g., in the UE side) may instruct the MAC layer to stop a running RA procedure after receiving a RACH configuration from the serving RAN. In some implementations, the MAC layer (e.g., in the UE side) may inform a RA failure event happens after receiving an updated RACH configuration from the RRC layer, and a running RA procedure may be stopped / terminated by the MAC entity.

[0084] Alternative 5: The UE may recognize the RA fails if the selected RA resources during the RA procedure are reconfigured by receiving the reconfiguration of the RACH configuration during the RA procedure.

[0085] Alternative 6: A timer value may be provided (e.g., in the RRC entity / layer of the UE side) in the reconfiguration of the RACH configuration. The UE may start a timer set to the timer value upon the reception of the reconfiguration of the RACH configuration. Upon the timer expires, the UE may release the used / determined RA / RO resources and apply the reconfigured RACH configuration. If the UE has completed the RA procedure or has considered the RA procedure as failed, the UE may stop the timer and apply the reconfigured RACH configuration. In other words, the UE may continue to execute the initialized RA procedure based on the previous RACH configuration until the timer expires.

[0086] In the action 206, among the candidate ROs identified in the action 204, multiple RO sets may be composited for individual feature usage. For instance, different RO sets may be used for Msg1 repetition with different repetition numbers. In addition to the repetition purpose, separate RO sets may also be applied for SDT / early data transmission, redcap features, respectively. The applicability check may be performed based on a new information IE (e.g., the FeatureCombinationROs IE). The FeatureCombinationROs IE may associate a set of ROs with a feature combination. The UE may apply the configured value to decide which ROs is prioritized for the applicable RO set usage under a particular feature. Table 3 below illustrates the FeatureCombinationROs IE, according to an example implementation of the present disclosure.

[0087] When the FeatureCombinationRO-r19 IE is presented, the UE may further check whether the listed respective features are applicable for the RO in the corresponding set. If the FeatureCombinationRO-r19 IE is not presented, the UE may determine that the candidate RO is shared / appliable for any purpose. In some implementations, if the FeatureCombinationRO-r19 IE is configured under multiple RACH configurations, there are three implementation options (1)-(3) as described below.

[0088] Option 1: Under the same purpose / feature, a single RO set may be composited. All the candidate resources identified from different RACH configurations after the action 204 may be selected to composite the RO set (e.g., this may mean that no FeatureCombinationROs IE is configured). The UE may perform the availability check for the preamble based on the indications from the upper layer. In some implementations, the UE may first identify the applicability based on the received feature and then perform the “filtering” on specific ROs while compositing the RO set.

[0089] Option 2: The candidate RO#A and RO#S may be grouped into separate sets from the RO#B. It may represent that under the same purpose / feature, at most three RO sets (e.g., the RO#B set, the RO#A set, and the RO#S set) may be composited. The gNB may additionally provide availability indications (e.g., the ROB-Mask / ROA-Mask / ROS-Mask) for respective RO types, and the UE may determine whether the candidate ROs is applicable. For example, if the ROA-Mask is set to “True,” and the ROS-Mask and the ROB-Mask are set to “False” when eRedCap is indicated in the FeatureCombination-r19 IE, the UE may determine that the set of RO#A is not available for a random access procedure for which eRedCap is not applicable, and determine that both set of RO#B and set of RO#S are available for the random access procedure for which eRedCap is not applicable.

[0090] Option 3: The partial ROs may be grouped to one RO set. The grouping criteria may be explicitly configured by the gNB via the ROPrioritization IE and the MaxRO IE or implicitly determined based on specific features. In some implementations, the gNB may configure a maximum number of candidate ROs per SSB using the MaxRO IE within a set, and the UE may group the candidate ROs in a specific order based on the ROPrioritization IE (e.g., if ROPrioritization set is ASB, then the pick-up order is the RO#A, followed by the RO#S, and then the RO#B) in each SSB, until reaching the maximum number (which may be predefined in the 3GPP TS / configured by the serving RAN via control signaling). Since the composition of RO set is further based on additional conditions, a set-specific availability check may not be performed, and the UE may determine the applicability based on feature categories. For example, when eRedCap is set to “True,” the UE may determine all candidate ROs within all RO set as unavailable for a random access procedure for which eRedCap is not applicable.

[0091] In the action 208, if there are more than one RO set is available, the UE may be required to perform selection based on prioritization among multiple RO sets. The featurePriorities IE may be still applied for this selection, and the UE may select the highest priority assigned in the featurePriorities IE among all the features applicable to this random access procedure and then repeat the procedure except for the features considered already. After the RO set selection, the UE may select random access resources and preamble based on the 3GPP TS.

[0092] In the action 210, when the resource and preamble are determined, the UE may transmit the preamble via the selected resource and try to monitor the response from the gNB as specified in the 3GPP TS. The preamble may be further partitioned based on the FeatureCombinationPreamble IE. While either no response or contention resolution is not successful, the UE may re-perform the actions 204-208 after the back off time. The applied back-off time may be determined based on the resource associated with the RACH configuration. When the gNB re-configures the RACH configuration before repeating the RA procedure, the UE may use a new setting for validity, availability, and applicability check.

[0093] During the re-attempt of the RA procedure by the actions 204-208, the UE may apply the same RO type within a certain number of re-attempt and fallback to other RO type after the certain number of re-attempt is achieved. The implementation details may include the following (a)-(c).

[0094] Option (a): Upon action 204, the UE may select one type of ROs among the RO#B, RO#A, and / or RO#S based on certain specified configured conditions prioritizations and / or DCI instruction (e.g., PDCCH order), and apply the same RO type if the configured condition still meet the criteria. If there are more than one RO type that meets the condition, but the previous selected RO type and / or indicated RO type (e.g., RO type indicated by the PDCCH order) doesn’t meet the criteria, it may be up to UE implementation to select one of them. If there is no RO type that meets the criteria, the UE may select the RO#B to perform the re-attempt.

[0095] Option (b): Upon action 204, the UE may directly apply the same RO without checking certain specified configured conditions prioritizations.

[0096] Option (c): Whether to apply the selection based on certain specified configured conditions prioritizations is further configured by the NW.

[0097] Moreover, the UE may indicate an early indication to the NW to facilitate the upcoming schedule during the RA. For example, the UE#S may select the RO#B or RO#S which both are valid for its RA purpose during the RA initialization. Regardless of which RO type is selected, the UE may make early indication to notify the NW that it is SBFD-aware UE, and the NW may schedule the UE#S on the corresponding SBFD PDSCH / PUSCH. In a case that the fallback occurs, there may be two possible fallback behaviors (1) and (2) and associated early indications.

[0098] Alternative (1): The RO#B may be selected for the re-attempt, and the UE may indicate it is SBFD-aware UE via transmitting a specific MSG1 / MSGA and the NW may still schedule the UE on the corresponding SBFD PDSCH / PUSCH.

[0099] Alternative (2): The RO#B may be selected for the re-attempt, and UE may indicate it is non-SBFD aware UE (e.g., this is reasonable especially the UE determines SBFD resource exists strong interference) and the NW may schedule the UE on the corresponding non-SBFD PDSCH / PUSCH. In other sense, it may imply that the UE#S may fall back to the UE#L if the certain number of re-attempt occurred during the RA procedure.

[0100] FIG. 3 is a flowchart illustrating an RO determination procedure under multiple RACH configurations, according to an example implementation of the present disclosure. In the action 302, the gNB may provide multiple RACH configurations. Each configuration may list potential ROs, and the potential ROs may be only valid for corresponding UE categories. The UE may receive the configured ROs from multiple RACH configurations. In the action 304, the UE may perform, based on the multiple RACH configurations, the SSB-RO mapping to identify the allocation of the valid RO per SSB. In the action 306, after channel quality selection criteria (e.g., comparing with a DL-RSRP threshold), the UE may select the SSB with associated ROs. In the action 308, the UE may perform masking to validate the candidate ROs for the RA trigger and RA type. When an RA triggering event is initiated, the UE may perform mask check on the associated ROs to identify the candidate ROs for the purpose. Moreover, the UE may perform separate mask check (e.g., in parallel or by sequence) to preclude certain candidate ROs for respective RA type. In the action 310, the UE may perform RO grouping to decide the availability and applicability of candidate ROs. The candidate ROs may be grouped into several RO sets based on the gNB’s configuration. The grouping criteria may rely on feature characteristics, repetition requirements, and additional rules provided by the gNB. With the multiple RO sets simultaneously meet the feature purpose, the UE may prioritize one of RO set as first RA attempt. The prioritization may also be configured by the gNB via different features and / or different RACH configurations (e.g., when the grouping is based on different RO types). In the action 312, UE may select one RO set and select the resource and preamble from the selected RO set, and try to complete the RA procedure.

[0101] In some implementations, the RACH configuration may be reconfigured, and the associated RO may be added / released. Upon every trigger, the UE may validate the candidate ROs based on the latest RACH configurations. The parameters listed in the RACH configuration may be re-initialized but the counter of preamble transmission and power ramping may keep the increment if the retransmission / repetition is on-going even receiving the new RRC configuration. This enables the UE to apply the new parameter setting immediately during the repetition and retransmission subject to the dynamics and able to provide more flexibility. On the contrary, to simplify the UE behavior during the RA procedure, the UE may suspend the received RACH configuration until the completeness of the RA procedure. In some implementations, the UE may remove all candidate RO#A and RO#S if there is reconfiguration occurred during the RA procedure (e.g., fallback to the legacy RACH configuration) and the new configuration may be applied in next triggering event, if any.

[0102] When the SBFD configuration option 2 is provided to the UE, there may be two RACH configurations, and the options (1)-(5) for performing the CFRA and relevant DCI format are listed below.

[0103] Option 1: Multiple PRACH Mask indexes may be appended in the DCI format 1_0. The order of PRACH Mask index may be (1) based on default order, (2) based on the reception order of the RACH configuration, or (3) configured by the NW. The UE may apply respective Mask check on different RO types (e.g., the UE may transmit the indicated preamble on the allowed RO occasions). The size of the DCI format may be increased by 4 bits, where the UE may determine the length of DCI format based on the RRC configuration (e.g., whether there is more than one RACH configuration and / or whether the SBFD function is enabled). More specifically, the UE may determine the number of bits of the PRACH Mask index field based on the number of RRC configurations (e.g., N*4 bits if N RACH configurations are provided).

[0104] Option 2: Single PRACH Mask index may be appended in the DCI format 1_0, and the mapping table may be different according to the condition of RACH configuration. When no SBFD RACH configuration is provided, the UE may use the existing table (e.g., the legacy PRACH Mask index table) to interpret the received PRACH Mask Indication Value. If the SBFD RACH configuration and / or the NES RACH configuration is provided and / or the SBFD function is enabled, the UE may use a new table (e.g., a PRACH Mask index table which is applicable for the RO#B, RO#A, and / or RO#S), where new table may specify the allowed RO occasion for both SBFD and legacy RO, and / or for SBFD RO (only). The UE may apply Mask indication based on the received RACH configuration and corresponding mapping table (e.g., a PRACH Mask index table which is applicable for the RO#B, RO#A, and / or RO#S). Same DCI format size as the legacy DCI format 1_0 used for initiating RA may be kept, and the UE may determine the PRACH Mask Indication and association RO occasion based on the RRC configuration.

[0105] Option 3: Single PRACH Mask index may be appended in DCI format 1_0 and the reserved bit may be used to indicate the allowed RO occasion for SBFD if the corresponding RACH configuration is provided. The bit value 0-10 may be used for indicating allowed RO occasion for legacy RO and the bit value 11-15 (e.g., 5 entries) may be used for indicating allowed RO occasion for SBFD RO. If the UE is configured with the RACH configuration for the RO#S and / or RO#A and / or the SBFD function is enabled, the reserved value in the legacy PRACH Mask index table may be used for indicating allowed RO occasion for the SBFD RO. The UE may apply the Mask indication based on the given value and identify the allowed occasion in either legacy RO or SBFD RO.

[0106] Option 4: The additional information IE (or additional information field) (e.g., RO_type and / or a DCI field used to indicate the RO type) may be added in the DCI format 1_0. In some implementations, 2-bit RO_type field may be added in the DCI format 1_0. For example, the value “00” may indicate that the PRACH Mask indication is applied to the legacy RO. The value “01” may indicate that the PRACH Mask indication is applied to the SBFD. The value “10” may indicate that the PRACH Mask indication is applied to both SBFD and legacy RO. The value “11” may be reserved. In some implementations, 1-bit RO type field may be added in the DCI format 1_0. For example, the value “0” may indicate that the PRACH Mask indication is applied to the legacy RO. The value “1” may indicate that the PRACH Mask indication is applied to the SBFD RO (only) or both legacy RO and SBFD RO. The UE may apply the RO_type new IE and / or RO type indicated in the DCI field together with the PRACH Mask indication to identify the allowed occasion in either legacy RO or SBFD RO while additional RACH configuration is provided. For example, if a UE receives the DCI (or a PDCCH order scrambled by C-RNTI) with the additional information field (e.g., used to indicate the RO type) set to ‘01’ and the PRACH Mask indication field with value 1, the UE may transmit the preamble on the SBFD RO with PRACH occasion index 1 (or on the ROs with the RO type indicated by the additional information field and with PRACH occasion index indicated by the PRACH Mask indication field).

[0107] Option 5: Extend the PRACH Mask Indication from 4 bit to 6 bit. There may be 64 entries, and the allowed RO occasion for either legacy RO (existing value 0-10) or SBFD RO or both may be defined, such that the UE may determine the allowed RO occasion based on the received PRACH Mask indication. The UE may determine the DCI format length based on the RRC configuration (e.g., if SBFD configuration is provided, the DCI format length may be increased by 2 bits.

[0108] Specifically, if the RO selection criteria are configured and the re-attempt occurs, the UE behavior may include the following options (1) and (2).

[0109] Option 1: No need to apply RO selection criteria during re-attempt and / or fallback case. In some implementations, the UE may select the SBFD RO for RA initialization and directly select the same RO type until a certain number of re-attempts is reached. During the fallback, the UE may also directly select a designated RO type which can be configured by the NW or by default. In some implementations, the UE may select the SBFD RO for RA initialization and directly select the same RO type until a certain number of re-attempts is reached. During the fallback, the UE may apply the RO selection to decide which RO type is used for the fallback behavior. If the SBFD RO do not meet the selection criteria, the UE may use the legacy RO for the fallback purpose. In some implementations, the UE may select the legacy RO for RA initialization and directly select the same RO type until a certain number of re-attempts is reached. During the fallback, the UE may directly select the SBFD RO for the fallback purpose. In some implementations, the UE may select the legacy RO for RA initialization and directly select the same RO type until a certain number of re-attempts is reached. During the fallback, the UE may apply the RO selection to decide which RO type is used for the fallback behavior. If the SBFD RO do not meet the selection criteria, the UE may still use the legacy RO (e.g., which may mean no fallback).

[0110] Option 2: The UE may need to apply the RO selection criteria during re-attempt. If the selection criteria do not meet, following behaviors are further specified. The UE may directly endorse fallback if no RO type meets the criteria. For example, the UE may select the SBFD RO for RA initialization, after checking RO selection result and if SBFD RO do not meet the criteria, the UE may select the legacy RO even a certain number of re-attempts doesn’t reach.

[0111] In some implementations, the UE may indicate its category during the RA by using specific preamble. For instance, a range of preamble index may be transmitted to the NW, and the NW may recognize that the UE is a SBFD-aware UE while receiving the corresponding preamble. When the UE fallback and select a legacy RO to perform the RA procedure, the UE may still perform the following actions (a) and (b).

[0112] (a) Use the specific range of preamble index and transmit it based on the legacy RO. The NW may recognize that the UE is the SBFD-aware UE even though the preamble is received in the legacy RO and try to schedule the UE on SBFD resource later.

[0113] (b) Don’t use the specific range of preamble index (e.g., the UE falls back to a legacy UE behavior) and transmit the preamble based on the legacy RO. The NW may recognize that the UE is not the SBFD-aware UE and may schedule the UE on non-SBFD resource later.

[0114] When the RA fails (e.g., try a certain number of re-attempt and fallback still doesn’t success), the UE may indicate the failure cause to the NW, where the failure cause may include the following (a)-(c).

[0115] (a) The RO occurrence and / or RO type of the initial selection and the re-attempt.

[0116] (b) The RO occurrence and / or RO type of the fallback selection.

[0117] (c) The RO selection criteria results.

[0118] FIG. 4 is a flowchart illustrating a method / process 400 performed by a UE for determining random access channel (RACH) occasions for a random access (RA) procedure, according to an example implementation of the present disclosure.

[0119] In the action 402, the process 400 may start by receiving, from a base station (BS), downlink control information (DCI) including a first field that indicates a first RACH occasion type or a second RACH occasion type.

[0120] In the action 404, the process 400 may determine, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type.

[0121] In the action 406, the process 400 may determine one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type. The process 400 may then end.

[0122] In some implementations, the DCI may further include a mask index field, and the process 400 may determine the one or more RACH occasions further based on the mask index field. In some implementations, the mask index field may indicate that the one or more RACH occasions associated with determined RACH occasion type are used for a physical random access channel (PRACH) transmission. In some implementations, the DCI may be a DCI format 1_0.

[0123] The steps / actions shown in FIG. 4 should not be construed as necessarily order dependent. The order in which the process is described is not intended to be construed as a limitation. Moreover, some of the actions shown in FIG. 4 may be omitted in some implementations and one or more actions shown in FIG. 4 may be combined.

[0124] The technical problem addressed by the method illustrated in FIG. 4 is how to efficiently and dynamically determine appropriate random access channel (RACH) occasions for a random access (RA) procedure in a user equipment (UE), particularly when supporting multiple RACH occasion types (e.g., first and second types) in complex wireless environments like 5G NR or NTN, where varying channel conditions, synchronization requirements, or resource availability may complicate RA configuration. The advantageous technical effect achieved by the method illustrated in FIG. 4 is that it enables the UE to dynamically select RACH occasions based on downlink control information (DCI) indicating specific RACH occasion types and a selected synchronization signal block (SSB), thereby improving RA procedure efficiency, ensuring compatibility with diverse network configurations (e.g., SBFD or legacy systems), reducing access latency, and enhancing resource utilization in dynamic and high-mobility scenarios like NTN or SDT.

[0125] FIG. 5 is a block diagram illustrating a node 500 for wireless communication in accordance with various aspects of the present disclosure. As illustrated in FIG. 5, a node 500 may include a transceiver 520, a processor 528, a memory 534, one or more presentation components 538, and at least one antenna 536. The node 500 may also include a radio frequency (RF) spectrum band module, a BS communications module, a network communications module, and a system communications management module, Input / Output (I / O) ports, I / O components, and a power supply (not illustrated in FIG. 5).

[0126] Each of the components may directly or indirectly communicate with each other over one or more buses 540. The node 500 may be a UE or a BS that performs various functions disclosed with reference to FIGS. 1 through 4.

[0127] The transceiver 520 has a transmitter 522 (e.g., transmitting / transmission circuitry) and a receiver 524 (e.g., receiving / reception circuitry) and may be configured to transmit and / or receive time and / or frequency resource partitioning information. The transceiver 520 may be configured to transmit in different types of subframes and slots including, but not limited to, usable, non-usable, and flexibly usable subframes and slot formats. The transceiver 520 may be configured to receive data and control channels.

[0128] The node 500 may include a variety of computer-readable media. Computer-readable media may be any available media that may be accessed by the node 500 and include volatile (and / or non-volatile) media and removable (and / or non-removable) media.

[0129] The computer-readable media may include computer-storage media and communication media. Computer-storage media may include both volatile (and / or non-volatile media), and removable (and / or non-removable) media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or data.

[0130] Computer-storage media may include RAM, ROM, EPROM, EEPROM, flash memory (or other memory technology), CD-ROM, Digital Versatile Disks (DVD) (or other optical disk storage), magnetic cassettes, magnetic tape, magnetic disk storage (or other magnetic storage devices), etc. Computer-storage media may not include a propagated data signal. Communication media may typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanisms and include any information delivery media.

[0131] The term “modulated data signal” may mean a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Communication media may include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above listed components should also be included within the scope of computer-readable media.

[0132] The memory 534 may include computer-storage media in the form of volatile and / or non-volatile memory. The memory 534 may be removable, non-removable, or a combination thereof. Example memory may include solid-state memory, hard drives, optical-disc drives, etc. As illustrated in FIG. 5, the memory 534 may store a computer-readable and / or computer-executable instructions 532 (e.g., software codes) that are configured to, when executed, cause the processor 528 to perform various functions disclosed herein, for example, with reference to FIGS. 1 through 4. Alternatively, the instructions 532 may not be directly executable by the processor 528 but may be configured to cause the node 500 (e.g., when compiled and executed) to perform various functions disclosed herein.

[0133] The processor 528 (e.g., having processing circuitry) may include an intelligent hardware device, e.g., a Central Processing Unit (CPU), a microcontroller, an ASIC, etc. The processor 528 may include memory. The processor 528 may process the data 530 and the instructions 532 received from the memory 534, and information transmitted and received via the transceiver 520, the baseband communications module, and / or the network communications module. The processor 528 may also process information to send to the transceiver 520 for transmission via the antenna 536 to the network communications module for transmission to a CN.

[0134] One or more presentation components 538 may present data indications to a person or another device. Examples of presentation components 538 may include a display device, a speaker, a printing component, a vibrating component, etc.

[0135] In view of the present disclosure, it is obvious that various techniques may be used for implementing the disclosed concepts without departing from the scope of those concepts. Moreover, while the concepts have been disclosed with specific reference to certain implementations, a person of ordinary skill in the art may recognize that changes may be made in form and detail without departing from the scope of those concepts. As such, the disclosed implementations are to be considered in all respects as illustrative and not restrictive. It should also be understood that the present disclosure is not limited to the particular implementations disclosed and many rearrangements, modifications, and substitutions are possible without departing from the scope of the present disclosure.

Claims

1. A user equipment (UE) for determining random access channel (RACH) occasions for a random access (RA) procedure, the UE comprising: 　　　　at least one processor; and 　　　　at least one non-transitory computer-readable medium coupled to at least one processor and storing one or more computer-executable instructions that, when executed by the at least one processor, cause the UE to: 　　　　　　　　receive, from a base station (BS), downlink control information (DCI) comprising a first field that indicates a first RACH occasion type or a second RACH occasion type; 　　　　　　　　determine, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type; and 　　　　　　　　determine one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type.

2. The UE of claim 1, wherein: 　　　　the DCI further comprises a mask index field, and 　　　　the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　　　　　determine the one or more RACH occasions further based on the mask index field.

3. The UE of claim 2, wherein the mask index field indicates that the one or more RACH occasions associated with determined RACH occasion type are used for a physical random access channel (PRACH) transmission.

4. The UE of claim 1, wherein the DCI is a DCI format 1_0.

5. A method performed by a user equipment (UE) for determining random access channel (RACH) occasions for a random access (RA) procedure, the method comprising: 　　　　receiving, from a base station (BS), downlink control information (DCI) comprising a first field that indicates a first RACH occasion type or a second RACH occasion type; 　　　　determining, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type; and 　　　　determining one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type.

6. A base station (BS) for determining random access channel (RACH) occasions for a random access (RA) procedure, the BS comprising: 　　　　at least one processor; and 　　　　at least one non-transitory computer-readable medium coupled to at least one processor and storing one or more computer-executable instructions that, when executed by the at least one processor, cause the BS to: 　　　　　　　　transmit, to a user equipment (UE), downlink control information (DCI) comprising a first field that indicates a first RACH occasion type or a second RACH occasion type, wherein the DCI causes the UE to: 　　　　　　　　　　　　determine, based on the DCI, a RACH occasion type including the first RACH occasion type or the second RACH occasion type; and 　　　　　　　　　　　　determine one or more RACH occasions based on a selected synchronization signal block (SSB) and the determined RACH occasion type.

7. The BS of claim 6, wherein: 　　　　the DCI further comprises a mask index field, and 　　　　the DCI further causes the UE to: 　　　　　　　　determine the one or more RACH occasions further based on the mask index field.

8. The BS of claim 7, wherein the mask index field indicates that the one or more RACH occasions associated with determined RACH occasion type are used for a physical random access channel (PRACH) transmission.

9. The BS of claim 6, wherein the DCI is a DCI format 1_0.

Images