Method and apparatus for handling random access channel configurations

Abstract

A method performed by a user equipment (UE) for handling random access channel (RACH) configurations is provided. The method receives a first RACH configuration for legacy random access occasions (ROs). The method receives a second RACH configuration for subband full duplex (SBFD) ROs. The method initiates a random access (RA) procedure. The method determines whether an indication is included in one of the first RACH configuration and the second RACH configuration. The method applies, based on the indication, an RO from the legacy ROs or from the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration.

Description

METHOD AND APPARATUS FOR HANDLING RANDOM ACCESS CHANNEL CONFIGURATIONS

[0001] The present disclosure is related to wireless communication and, more specifically, to a User Equipment (UE), Base Station (BS), and method for handling random access channel (RACH) configurations 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 handling random access channel (RACH) configurations in the wireless communication networks.

[0004] In a first aspect of the present disclosure, a UE for handling random access channel (RACH) configurations 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 a first RACH configuration for legacy random access occasions (ROs); receive a second RACH configuration for subband full duplex (SBFD) ROs; initiate a random access (RA) procedure; determine whether an indication is included in one of the first RACH configuration and the second RACH configuration; and apply, based on the indication, an RO from the legacy ROs or from the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration.

[0005] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: apply the RO from the legacy ROs and the SBFD ROs for the RA procedure in response to determining that the indication is not included in one of the first RACH configuration and the second RACH configuration.

[0006] In some implementations of the first aspect, the second RACH configuration is received via system information block 1 (SIB1).

[0007] In some implementations of the first aspect, applying, based on the indication, the RO from the legacy ROs or from the SBFD ROs for the RA procedure includes: applying the RO from the legacy ROs for the RA procedure in response to determining that the indication indicates that the legacy ROs are used for the RA procedure; and applying the RO from the SBFD ROs for the RA procedure in response to determining that the indication indicates that the SBFD ROs are used for the RA procedure.

[0008] In some implementations of the first aspect, the first RACH configuration includes a first parameter for the legacy ROs, and the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: determine whether the second RACH configuration includes a second parameter for the SBFD ROs; determine the SBFD ROs based on the first parameter in response to determining that the second RACH configuration does not comprise the second parameter; and determine the SBFD ROs based on the second parameter in response to determining that the second RACH configuration includes the second parameter.

[0009] In some implementations of the first aspect, the indication is associated with a triggering event or an RA type for the RA procedure, the triggering event includes one of a handover, a beam failure recovery (BFR), a system information (SI) request, an on-demand synchronization signal block (SSB) request, an on-demand system information block 1 (SIB1) request, a physical downlink control channel (PDCCH) order, a scheduling request failure, a timing advance (TA) acquisition, and an early uplink (UL) synchronization with Layer 1 / Layer 2 triggered mobility (LTM), and the RA type includes one of a 4-step RA, a 2-step RA, a contention-based random access (CBRA), and a contention-free random access (CFRA).

[0010] In a second aspect of the present disclosure, a method performed by a user equipment (UE) for handling random access channel (RACH) configurations is provided. The method includes: receiving a first RACH configuration for legacy random access occasions (ROs); receiving a second RACH configuration for subband full duplex (SBFD) ROs; initiating a random access (RA) procedure; determining whether an indication is included in one of the first RACH configuration and the second RACH configuration; and applying, based on the indication, an RO from the legacy ROs or from the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration.

[0011] In a third aspect of the present application, a BS for handling random access channel (RACH) configurations 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: determine whether to include an indication in one of a first RACH configuration and a second RACH configuration; transmit the first RACH configuration for legacy random access occasions (ROs); transmit the second RACH configuration for subband full duplex (SBFD) ROs; initiate a random access (RA) procedure; and apply, based on the indication, the legacy ROs or the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration.

[0012] In some implementations of the third aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the BS to: apply the legacy ROs and SBFD ROs for the RA procedure in response to determining that the indication is not included in one of the first RACH configuration and the second RACH configuration.

[0013] In some implementations of the third aspect, the second RACH configuration is transmitted via system information block 1 (SIB1).

[0014] In some implementations of the third aspect, applying, based on the indication, the legacy ROs or SBFD ROs for the RA procedure includes: applying the legacy ROs for the RA procedure in response to determining that the indication indicates that the legacy ROs are used for the RA procedure; and applying the SBFD ROs for the RA procedure in response to determining that the indication indicates that the SBFD ROs are used for the RA procedure.

[0015] In some implementations of the third aspect, the first RACH configuration includes a first parameter for the legacy ROs, and the one or more computer-executable instructions, when executed by the at least one processor, further cause the BS to: determine whether the second RACH configuration includes a second parameter for the SBFD ROs; determine the SBFD ROs based on the first parameter in response to determining that the second RACH configuration does not comprise the second parameter; and determine the SBFD ROs based on the second parameter in response to determining that the second RACH configuration includes the second parameter.

[0016] In some implementations of the third aspect, the indication is associated with a triggering event or an RA type for the RA procedure, the triggering event includes one of a handover, a beam failure recovery (BFR), a system information (SI) request, an on-demand synchronization signal block (SSB) request, an on-demand system information block 1 (SIB1) request, a physical downlink control channel (PDCCH) order, a scheduling request failure, a timing advance (TA) acquisition, and an early uplink (UL) synchronization with Layer 1 / Layer 2 triggered mobility (LTM), and the RA type includes one of a 4-step RA, a 2-step RA, a contention-based random access (CBRA), and a contention-free random access (CFRA).

[0017] 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.

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

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

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

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

[0022] FIG. 5 is a flowchart illustrating a method / process performed by a BS for handling random access channel (RACH) configurations, according to an example implementation of the present disclosure.

[0023] FIG. 6 is a block diagram illustrating a node for wireless communication, according to an example implementation of the present disclosure.

[0024] Some of the abbreviations used in the present disclosure include: Abbreviation　　　　Full name 3GPP　　　　3rdGeneration Partnership Project 5G　　　　5thGeneration BFR　　　　Beam Failure Recovery BS　　　　Base Station CBRA　　　　Contention-Based Random Access CFRA　　　　Contention-Free Random Access DCI　　　　Downlink Control Information DL　　　　Downlink E-UTRA(N)　　　　Evolved Universal Terrestrial Radio Access (Network) EN-DC　　　　E-UTRA NR Dual Connectivity EPC　　　　Evolved Packet Core FR　　　　Frequency Range IAB　　　　Integrated Access and Backhaul IAB-MT　　　　Integrated Access and Backhaul Mobile Termination IE　　　　Information Element LAN　　　　Local Area Network LTE　　　　Long Term Evolution LTM　　　　Layer 1 / Layer 2 Triggered Mobility MAC　　　　Medium Access Control MAC CE　　　　MAC Control Element MSG　　　　Message NAS　　　　Non-Access Stratum NE-DC　　　　NR - E-UTRA Dual Connectivity NES　　　　Network Energy Saving NR　　　　New Radio NR-U　　　　NR Unlicensed NW　　　　Network NSSAI　　　　Network Slice Selection Assistance Information PCell　　　　Primary Cell PCI　　　　Physical Cell Identity PDCCH　　　　Physical Downlink Control Channel PDSCH　　　　Physical Downlink Shared Channel PDU　　　　Protocol Data Unit PHY　　　　Physical (layer) PLMN　　　　Public Land Mobile Network PRACH　　　　Physical Random Access Channel PSCell　　　　Primary SCG Cell / Primary Secondary Cell PUCCH　　　　Physical Uplink Control Channel PUSCH　　　　Physical Uplink Shared Channel RA　　　　Random Access RACH　　　　Random Access Channel RAN　　　　Radio Access Network RAR　　　　Random Access Response RAT　　　　Radio Access Technology RF　　　　Radio Frequency RNTI　　　　Radio Network Temporary Identifier RRC　　　　Radio Resource Control RS　　　　Reference Signal RSRP　　　　Reference Signal Received Power SBFD　　　　Sub-Band Full Duplexing SCell　　　　Secondary Cell SCG　　　　Secondary Cell Group SDT　　　　Small Data Transmission SI　　　　System Information SIB　　　　System Information Block SIB1　　　　System Information Block 1 SL　　　　Sidelink SN　　　　Secondary Node SNPN　　　　Stand-alond Non-Public Network SSB　　　　Synchronization Signal Block TA　　　　Timing Advance TS　　　　Technical Specification UE　　　　User Equipment UL　　　　Uplink V2X　　　　Vehicle-to-Everything WID　　　　Work Item Description WUS　　　　Wake-Up-Signal / Wake-Up-Signaling

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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).

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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”.

[0050] In the 3GPP Rel-19, the objective of the NES WID may specify the adaptation of a common signal or channel transmission. The adaptation may occur for the PRACH in the time domain, where the gNB may adjust the 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.

[0051] In some implementations, an additional RO configuration may be provided for the 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.

[0052] 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, specifying repetition of Msg3 and Msg1 (or preamble). However, when required, repetition of Msg3 or Msg1 may increase operations of the gNB, resulting in higher power consumption.

[0053] Consequently, determining how to jointly address the aforementioned designs to meet various requirements may remain unspecified. Specifically, whether to apply the same or different RA procedures under various RACH configurations to fulfill requirements of different vendors may require further consideration.

[0054] From the perspective of UE capabilities, the following four categories of UEs (a)-(d) may be defined based on supported features and specifications:

[0055] (a) 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 UE#L may support repetition mechanisms for Msg1 and Msg3 and may perform the RA procedure based on the basic RO.

[0056] (b) 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.

[0057] (c) The SBFD-aware UE, referred to as UE#S, may perform transmission and reception on SBFD resources and may initiate 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 based on the configuration. For example, the SBFD-aware UE (UE#S) may be a Rel-19 UE supporting the SBFD feature.

[0058] (d) 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 based on the configuration.

[0059] 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.

[0060] (a) 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).

[0061] (b) 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.

[0062] (c) 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.

[0063] 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.

[0064] 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. In some implementations, 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 presence of multiple configurations may introduce complexity in determining the appropriate RO for the RA procedure. In some implementations, 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 transmission attempts may require further specification.

[0065] 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 require 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.

[0066] 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. The gNB may provide RA parameters applicable to the configured ROs.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] The gNB may reconfigure the RACH configuration (e.g., when additional RACH configuration is released, and the RO#A becomes invalid), and the UE may receive the configuration in the action 204. The following approaches (a)-(f) are proposed to react with this condition.

[0077] (a) Upon receiving a reconfiguration for the RO#A or the RO#S, the UE may re-perform the action 204 again (to flush the current initialization and candidate resource set determination) based on new configurations.

[0078] (b) The UE may remove all selected RO#A and RO#S, regardless of the reconfiguration settings. 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.

[0079] (c) The UE may ignore the reconfiguration until the initiated RA procedure is completed or is recognized as RA fail.

[0080] (d) The UE may recognize the RA procedure as failed upon receiving the reconfiguration of the RACH configuration during the RA procedure. In some implementations, the RRC layer / entity of the UE may instruct the MAC layer to terminate / stop a running RA procedure after receiving the RACH configuration from the serving RAN. In some implementations, the MAC layer of the UE may report an RA failure event after receiving the updated RACH configuration from the RRC layer. The running RA procedure may be stopped / terminated by the MAC entity.

[0081] (e) The UE may recognize the RA procedure as failed if the selected RA resources during the RA procedure are reconfigured by receiving the reconfiguration of the RACH configuration during the RA procedure.

[0082] (f) A timer value may be provided (e.g., in the RRC entity / layer of the UE) in the reconfiguration of the RACH configuration. The UE may start a timer set to the timer value upon receiving the reconfiguration of the RACH configuration. When the timer expires, the UE may release the used or determined RA / RO resources and apply the reconfigured RACH configuration. If the UE has completed the RA procedure or has considered the RA procedure failed, the UE may stop the timer and apply the reconfigured RACH configuration. In this approach, the UE may continue performing the initialized RA procedure based on the previous RACH configuration until the timer expires.

[0083] 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 2 below illustrates the FeatureCombinationROs IE, according to an example implementation of the present disclosure.

[0084] When the FeatureCombinationRO-r19 IE is presented, the UE may further check whether the listed respective features are applicable to 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 (a)-(c) as described below.

[0085] (a) 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.

[0086] (b) 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 MOB-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.

[0087] (c) 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., prioritizing 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

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

[0093] In the action 402, the process 400 may start by receiving a first RACH configuration for legacy random access occasions (ROs). In the action 404, the process 400 may receive a second RACH configuration for subband full duplex (SBFD) ROs. In the action 406, the process 400 may initiate a random access (RA) procedure. In the action 408, the process 400 may determine whether an indication is included in one of the first RACH configuration and the second RACH configuration. In the action 410, the process 400 may apply, based on the indication, an RO from the legacy ROs or from the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration. The process 400 may then end.

[0094] In some implementations, the process 400 may apply the RO from the legacy ROs and the SBFD ROs for the RA procedure in response to determining that the indication is not included in one of the first RACH configuration and the second RACH configuration.

[0095] In some implementations, the second RACH configuration may be received via system information block 1 (SIB1).

[0096] In some implementations, applying, based on the indication, the RO from the legacy ROs or from the SBFD ROs for the RA procedure may include: applying the RO from the legacy ROs for the RA procedure in response to determining that the indication indicates that the legacy ROs are used for the RA procedure; and applying the RO from the SBFD ROs for the RA procedure in response to determining that the indication indicates that the SBFD ROs are used for the RA procedure.

[0097] In some implementations, the first RACH configuration may include a first parameter for the legacy ROs. The process 400 may determine whether the second RACH configuration includes a second parameter for the SBFD ROs, determine the SBFD ROs based on the first parameter in response to determining that the second RACH configuration does not include the second parameter, and determine the SBFD ROs based on the second parameter in response to determining that the second RACH configuration includes the second parameter.

[0098] In some implementations, the indication may be associated with a triggering event or an RA type for the RA procedure. The triggering event may include one of a handover, a beam failure recovery (BFR), a system information (SI) request, an on-demand synchronization signal block (SSB) request, an on-demand system information block 1 (SIB1) request, a physical downlink control channel (PDCCH) order, a scheduling request failure, a timing advance (TA) acquisition, and an early uplink (UL) synchronization with Layer 1 / Layer 2 triggered mobility (LTM). The RA type may include one of a 4-step RA, a 2-step RA, a contention-based random access (CBRA), and a contention-free random access (CFRA).

[0099] 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.

[0100] The technical problem addressed by the method illustrated in FIG. 4 is how to efficiently manage multiple random access channel (RACH) configurations for a user equipment (UE) to initiate a random access (RA) procedure under varying network conditions, such as legacy and subband full duplex (SBFD) configurations, while ensuring compatibility with different UE capabilities and RO types. The advantageous technical effect achieved by the method illustrated in FIG. 4 is enhanced flexibility and efficiency in performing the RA procedure across diverse network configurations. By enabling the UE to dynamically select between legacy ROs and SBFD ROs based on an indication in the received RACH configurations, the method ensures reduced access latency for SBFD-aware UEs while maintaining compatibility with legacy UEs, optimizes resource utilization, and supports network adaptability to specific operational scenarios, such as SBFD-specific procedures, thereby improving overall network performance and UE access reliability.

[0101] FIG. 5 is a flowchart illustrating a method / process 500 performed by a BS for handling random access channel (RACH) configurations, according to an example implementation of the present disclosure.

[0102] In the action 502, the process 500 may start by determining whether to include an indication in one of a first RACH configuration and a second RACH configuration. In the action 504, the process 500 may transmit the first RACH configuration for legacy random access occasions (ROs). In the action 506, the process 500 may transmit the second RACH configuration for subband full duplex (SBFD) ROs. In the action 508, the process 500 may initiate a random access (RA) procedure. In the action 510, the process 500 may apply, based on the indication, the legacy ROs or the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration. The process 500 may then end.

[0103] In some implementations, the process 500 may apply the legacy ROs and SBFD ROs for the RA procedure in response to determining that the indication is not included in one of the first RACH configuration and the second RACH configuration.

[0104] In some implementations, the second RACH configuration may be transmitted via system information block 1 (SIB1).

[0105] In some implementations, applying, based on the indication, the legacy ROs or SBFD ROs for the RA procedure may include: applying the legacy ROs for the RA procedure in response to determining that the indication indicates that the legacy ROs are used for the RA procedure; and applying the SBFD ROs for the RA procedure in response to determining that the indication indicates that the SBFD ROs are used for the RA procedure.

[0106] In some implementations, the first RACH configuration may include a first parameter for the legacy ROs. The process 500 may determine whether the second RACH configuration includes a second parameter for the SBFD ROs, determine the SBFD ROs based on the first parameter in response to determining that the second RACH configuration does not include the second parameter, and determine the SBFD ROs based on the second parameter in response to determining that the second RACH configuration includes the second parameter.

[0107] In some implementations, the indication may be associated with a triggering event or an RA type for the RA procedure. The triggering event may include one of a handover, a beam failure recovery (BFR), a system information (SI) request, an on-demand synchronization signal block (SSB) request, an on-demand system information block 1 (SIB1) request, a physical downlink control channel (PDCCH) order, a scheduling request failure, a timing advance (TA) acquisition, and an early uplink (UL) synchronization with Layer 1 / Layer 2 triggered mobility (LTM). The RA type may include one of a 4-step RA, a 2-step RA, a contention-based random access (CBRA), and a contention-free random access (CFRA).

[0108] The steps / actions shown in FIG. 5 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. 5 may be omitted in some implementations and one or more actions shown in FIG. 5 may be combined.

[0109] The method illustrated in FIG. 5 is similar to that in FIG. 4, except that it is described from the perspective of the BS (instead of the UE).

[0110] FIG. 6 is a block diagram illustrating a node 600 for wireless communication in accordance with various aspects of the present disclosure. As illustrated in FIG. 6, a node 600 may include a transceiver 620, a processor 628, a memory 634, one or more presentation components 638, and at least one antenna 636. The node 600 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. 6).

[0111] Each of the components may directly or indirectly communicate with each other over one or more buses 640. The node 600 may be a UE or a BS that performs various functions disclosed with reference to FIGS. 2 through 5.

[0112] The transceiver 620 has a transmitter 622 (e.g., transmitting / transmission circuitry) and a receiver 624 (e.g., receiving / reception circuitry) and may be configured to transmit and / or receive time and / or frequency resource partitioning information. The transceiver 620 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 620 may be configured to receive data and control channels.

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

[0114] 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.

[0115] 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.

[0116] 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.

[0117] The memory 634 may include computer-storage media in the form of volatile and / or non-volatile memory. The memory 634 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. 6, the memory 634 may store a computer-readable and / or computer-executable instructions 632 (e.g., software codes) that are configured to, when executed, cause the processor 628 to perform various functions disclosed herein, for example, with reference to FIGS. 2 through 5. Alternatively, the instructions 632 may not be directly executable by the processor 628 but may be configured to cause the node 600 (e.g., when compiled and executed) to perform various functions disclosed herein.

[0118] The processor 628 (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 628 may include memory. The processor 628 may process the data 630 and the instructions 632 received from the memory 634, and information transmitted and received via the transceiver 620, the baseband communications module, and / or the network communications module. The processor 628 may also process information to send to the transceiver 620 for transmission via the antenna 636 to the network communications module for transmission to a CN.

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

[0120] 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 handling random access channel (RACH) configurations, 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 a first RACH configuration for legacy random access occasions (ROs); 　　　　　　　　receive a second RACH configuration for subband full duplex (SBFD) ROs; 　　　　　　　　initiate a random access (RA) procedure; 　　　　　　　　determine whether an indication is included in one of the first RACH configuration and the second RACH configuration; and 　　　　　　　　apply, based on the indication, an RO from the legacy ROs or from the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration.

2. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　apply the RO from the legacy ROs and the SBFD ROs for the RA procedure in response to determining that the indication is not included in one of the first RACH configuration and the second RACH configuration.

3. The UE of claim 1, wherein the second RACH configuration is received via system information block 1 (SIB1).

4. The UE of claim 1, wherein applying, based on the indication, the RO from the legacy ROs or from the SBFD ROs for the RA procedure comprises: 　　　　applying the RO from the legacy ROs for the RA procedure in response to determining that the indication indicates that the legacy ROs are used for the RA procedure; and 　　　　applying the RO from the SBFD ROs for the RA procedure in response to determining that the indication indicates that the SBFD ROs are used for the RA procedure.

5. The UE of claim 1, wherein: 　　　　the first RACH configuration comprises a first parameter for the legacy ROs, and 　　　　the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　　　　　determine whether the second RACH configuration comprises a second parameter for the SBFD ROs; 　　　　　　　　determine the SBFD ROs based on the first parameter in response to determining that the second RACH configuration does not comprise the second parameter; and 　　　　　　　　determine the SBFD ROs based on the second parameter in response to determining that the second RACH configuration comprises the second parameter.

6. The UE of claim 1, wherein: 　　　　the indication is associated with a triggering event or an RA type for the RA procedure, the triggering event comprises one of a handover, a beam failure recovery (BFR), a system information (SI) request, an on-demand synchronization signal block (SSB) request, an on-demand system information block 1 (SIB1) request, a physical downlink control channel (PDCCH) order, a scheduling request failure, a timing advance (TA) acquisition, and an early uplink (UL) synchronization with Layer 1 / Layer 2 triggered mobility (LTM), and 　　　　the RA type comprises one of a 4-step RA, a 2-step RA, a contention-based random access (CBRA), and a contention-free random access (CFRA).

7. A method performed by a user equipment (UE) for handling random access channel (RACH) configurations, the method comprising: 　　　　receiving a first RACH configuration for legacy random access occasions (ROs); 　　　　receiving a second RACH configuration for subband full duplex (SBFD) ROs; 　　　　initiating a random access (RA) procedure; 　　　　determining whether an indication is included in one of the first RACH configuration and the second RACH configuration; and 　　　　applying, based on the indication, an RO from the legacy ROs or from the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration.

8. A base station (BS) for handling random access channel (RACH) configurations, 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: 　　　　　　　　determine whether to include an indication in one of a first RACH configuration and a second RACH configuration; 　　　　　　　　transmit the first RACH configuration for legacy random access occasions (ROs); 　　　　　　　　transmit the second RACH configuration for subband full duplex (SBFD) ROs; 　　　　　　　　initiate a random access (RA) procedure; and 　　　　　　　　apply, based on the indication, the legacy ROs or the SBFD ROs for the RA procedure in response to determining that the indication is included in one of the first RACH configuration and the second RACH configuration.

9. The BS of claim 8, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the BS to: 　　　　apply the legacy ROs and SBFD ROs for the RA procedure in response to determining that the indication is not included in one of the first RACH configuration and the second RACH configuration.

10. The BS of claim 8, wherein the second RACH configuration is transmitted via system information block 1 (SIB1).

11. The BS of claim 8, wherein applying, based on the indication, the legacy ROs or SBFD ROs for the RA procedure comprises: 　　　　applying the legacy ROs for the RA procedure in response to determining that the indication indicates that the legacy ROs are used for the RA procedure; and 　　　　applying the SBFD ROs for the RA procedure in response to determining that the indication indicates that the SBFD ROs are used for the RA procedure.

12. The BS of claim 8, wherein: 　　　　the first RACH configuration comprises a first parameter for the legacy ROs, and 　　　　the one or more computer-executable instructions, when executed by the at least one processor, further cause the BS to: 　　　　　　　　determine whether the second RACH configuration comprises a second parameter for the SBFD ROs; 　　　　　　　　determine the SBFD ROs based on the first parameter in response to determining that the second RACH configuration does not comprise the second parameter; and 　　　　　　　　determine the SBFD ROs based on the second parameter in response to determining that the second RACH configuration comprises the second parameter.

13. The BS of claim 8, wherein: 　　　　the indication is associated with a triggering event or an RA type for the RA procedure, the triggering event comprises one of a handover, a beam failure recovery (BFR), a system information (SI) request, an on-demand synchronization signal block (SSB) request, an on-demand system information block 1 (SIB1) request, a physical downlink control channel (PDCCH) order, a scheduling request failure, a timing advance (TA) acquisition, and an early uplink (UL) synchronization with Layer 1 / Layer 2 triggered mobility (LTM), and 　　　　the RA type comprises one of a 4-step RA, a 2-step RA, a contention-based random access (CBRA), and a contention-free random access (CFRA).

Images