Method and systems for indicating random access channel (RACH) occasions in communication systems

Abstract

The present disclosure discloses a method for indicating required RACH occasions using a low-overhead signaling mechanism that minimizes number of bits required for indication. The method comprises selecting (702) a PRACH Configuration Index that provides RACH occasions in a first type of slots within a RACH frame and generating (706) a bitmap in which slots having wanted RACH occasions are represented by a first value and slots having unwanted RACH occasions are represented by a second value. The method comprises identifying (708) whether the bitmap exhibits a repetition pattern and upon identifying the repetition pattern, generating (710) a compressed bitmap corresponding to a portion of the bitmap that defines the repetition pattern, appending a repeat indicator with the compressed bitmap, and transmitting (712) the compressed bitmap along with the repeat indicator to UEs (106) for performing random access during the wanted RACH occasions indicated in the compressed bitmap.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to wireless communications. More particularly, the present disclosure relates to indicating required Random Access Channel (RACH) occasions to User Equipment (UEs) in wireless communication systems.BACKGROUND

[0002] Wireless communication systems have undergone rapid and continuous advancements, particularly in the areas of Random Access Channels (RACH) transmissions, to meet increasing demands for higher uplink capacity, lower latency, and overall network efficiency. In the wireless communication systems, the RACH plays a fundamental role as an initial procedure by which a User Equipment (UE) establishes communication with a base station or network. The base station may include a Next Generation Node B (gNB) in Fifth Generation (5G) New Radio (NR) systems or an evolved Node B (eNB) in Fourth Generation (4G) Long-Term Evolution (LIE) networks. Similar principles also apply in legacy systems such as Third Generation (3G) Wideband Code Division Multiple Access (WCDMA).

[0003] The RACH is a mechanism through which the UE initiates uplink (UL) synchronization and acquires a temporary or specific identifier (ID) necessary for subsequent radio access procedures. In other words, the RACH is a first UL signal sent from the UE to the base station, indicating that the UE wants to connect to the network. Further, the RACH is also used to request uplink resources. The UE performs Downlink (DL) synchronization with respect to the network before performing the RACH. The DL synchronization in the UE is achieved by correlating with Primary Synchronization Signal (PSS) and Secondary Synchronization Signal (SSS) present in Synchronization Signal Block (SSB) burst.

[0004] Information about RACH may be acquired by decoding System Information Block Type 1 (SIB1) which is sent to the UE over Physical Downlink Shared Channel (PDSCH). The network broadcasts RACH configurations in the SIB1 to enable the UE to execute random access procedure. The UE on decoding the SIB1, obtains information related to common configuration of the RACH, such as, total number of preambles allowed in RACH, SSB to RACH occasion mapping, contention-based preamble per SSB, Physical Random Access Channel (PRACH)configuration index (PCI), start frequency location of RACH in terms of Physical Resource Blocks (PRB), RACH receive target power, and the like.

[0005] Conventional wireless communication systems that employ Time Division Duplexing (TDD) are generally designed to be downlink-heavy, meaning that a larger portion of timefrequency resources is typically allocated to downlink transmissions than to uplink transmissions. However, with the evolution of advanced applications including cloud-based services, interactive video, and massive machine-type communications, requirements for higher uplink capacity has grown substantially. To address such requirements, various approaches have been explored by the 3rd Generation Partnership Project (3GPP). One such approach involves dynamically carving out a portion of spectrum or time-frequency resources traditionally reserved for downlink transmissions and making them available for uplink operation. Within a conventional TDD band, this concept allows a smaller dedicated uplink region, commonly referred to as an uplink sub-band, to be defined inside slots that would otherwise carry only downlink signals. The remaining portion of those slots continues to carry downlink traffic.

[0006] In such configurations, slots may be categorized as (i) downlink slots “D” reserved for only downlink transmissions, (ii) uplink slots “U” reserved for only uplink transmissions, and (iii) mixed slots “X” where both uplink and downlink transmissions may take place. The mixed operation introduces unique challenges for the random access procedure, which need to be addressed. For example, providing indication of RACH Occasions in the mixed slots to the UEs may lead wastage of valuable uplink resources and reducing overall uplink throughput in the communication systems.

[0007] The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.SUMMARY

[0008] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

[0009] In some aspects, a method of wireless communication within a communication system is disclosed. The method comprises selecting, from a Physical Random Access Channel (PRACH) configuration table, a PRACH Configuration Index (PCI) that provides a plurality of RACH occasions in a first type of slots within a RACH frame; categorizing the plurality of RACH occasions into wanted RACH occasions and unwanted RACH occasions; generating a bitmap in which slots having the wanted RACH occasions are represented by a first logical value and slots having the unwanted RACH occasions are represented by a second logical value; identifying whether the generated bitmap exhibits a repetition pattern of the wanted and unwanted RACH occasions within the RACH frame; and upon identifying the repetition pattern within the generated bitmap: generating a compressed bitmap corresponding to a portion of the bitmap that defines the repetition pattern and appending a repeat indicator with the compressed bitmap, the repeat indicator indicating whether the compressed bitmap is to be repeated until an end of the RACH frame; and transmitting the compressed bitmap along with the repeat indicator to one or more User Equipment (UEs) for performing random access during the wanted RACH occasions indicated in the compressed bitmap.

[0010] In some aspects, a method of wireless communication within a communication system is disclosed. The method comprises receiving, from a base station, a bitmap along with a repeat indicator, the repeat indicator indicating whether the bitmap is to be repeated until an end of a Random- Access Channel (RACH) frame; decoding the bitmap according to the repeat indicator to obtain an expanded bitmap representing RACH occasions during which random access is permitted; and performing random access during the RACH occasions.

[0011] In this manner, the RACH occasions that are invalid or unwanted are identified and not considered for generating a bitmap. The valid or wanted RACH occasions are informed to the UEsin a bit compressed way to save information bits used for transmission and also improving uplink throughput by avoiding unwanted RACH occasions.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. The same numbers are used throughout the figures to reference features and components. Some embodiments of at least one of devices and methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:

[0013] FIG. 1 illustrates an exemplary wireless communication system 100.

[0014] FIG. 2A-2C illustrate exemplary configurations 200 of a wireless communication frame.

[0015] FIG. 3 illustrates a configuration table 300 having various Physical Random-Access Channel (PRACH) configurations.

[0016] FIG. 4 illustrates an example RACH frame 400.

[0017] FIG. 5 illustrates a method 500 of generating and transmitting a bitmap for RACH occasions.

[0018] FIG. 6A and 6B illustrate various example RACH frames and associated bitmaps.

[0019] FIG. 7 illustrates a flow chart of an exemplary method 700 of wireless communication within a communication system.

[0020] FIG. 8 illustrates a flow chart of another exemplary method 800 of wireless communication within a communication system.

[0021] FIG. 9 which shows a high-level block diagram of an apparatus 900.DETAILED DESCRIPTION

[0022] In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0023] While the disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however, that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the spirit and the scope of the disclosure.

[0024] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a device or system or apparatus proceeded by “comprises... a” does not, without more constraints, preclude the existence of other elements or additional elements in the device, system, or apparatus.

[0025] In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

[0026] It may be noted that the techniques of the present disclosure have been explained with respect to Sub-Band non- overlapping Full Duplex (SBFD) communication systems. However, thepresent disclosure is not limited to SBFD based communication system and a person skilled in the art will appreciate that the proposed techniques are equally applicable for other communication systems as well such as full duplex systems, Non-terrestrial networks (NTN), Hybrid Duplex NTN where RACH slots are even scarcer, Unlicensed spectrum access (NR-U) where RACH occasions must adapt to listen-before-talk: gaps, Wi-Fi random access / grant- free access where bitmap approach is used to compress contention windows.

[0027] FIG. 1 illustrates an exemplary wireless communication system 100, in which some embodiments of the present disclosure may be implemented. The wireless communication system 100 depicts a base station 102 configured to serve a geographical area or a cell 104. The base station 102 may be configured to provide wireless services to at least one UE 106 (served by the associated cell 104) via a communication network 108.

[0028] The base station 102 may include a Next Generation Node B (gNB) in Fifth Generation (5G) New Radio (NR) systems or an evolved Node B (eNB) in Fourth Generation (4G) Long- Term Evolution (LIE) networks. However, the present disclosure is not limited thereto and the techniques of the present disclosure are equally applicable for future wireless communications as well such as, but not limited to, 6G wireless communications. Further, the principles also apply in legacy systems such as Third Generation (3G) Wideband Code Division Multiple Access (WCDMA).

[0029] The at least one UE 106 may be any mobile or non-mobile computing device including, but not limited to, a phone (e.g., a cellular phone or smart phone), a pager, a laptop computer, a desktop computer, a wireless handset, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system device, or any other suitable computing device including a wired or wireless communications interface. In some embodiments of the present disclosure, the at least one UE 106 may be Internet-of-Things (loT)-enabled device including, but not limited to, vehicles configured to communicate with the RAN node or a core network.

[0030] The UE 106 may work on multiple platforms and / or Operating Systems (OS) to perform different operations related to wireless communication. In an example scenario, the UE 106 mayinitiate a connection with the base station 102 under a variety of network-triggered or UE-triggered conditions. The conditions typically represent network procedures that require the UE 106 to establish or re-establish radio connectivity with the base station. The conditions may include, for example, initiation of a Random Access Channel (RACH) procedure for uplink synchronization or for obtaining a temporary identifier for radio access, initial access to the base station 102 when the UE 106 transitions from a Radio Resource Control (RRC) idle state (RRC IDLE) to an active state, transition of the UE 106 from an RRC inactive state (RRC INACTIVE) to an RRC CONNECTED state for resuming data transmission, RRC connection re-establishment following a connection failure or a loss of synchronization. The conditions may also include handover between cells or base stations, beam failure recovery in scenarios employing beamforming, synchronous reconfiguration, timing alignment during addition of a Secondary Cell (SCell), downlink (DL) out-of-sync events, uplink (UL) out-of-sync conditions, situations where the Scheduling Request (SR) has reached its maximum number of transmissions, uplink data arrival events, requests for on-demand system information. It shall be noted that the conditions mentioned hereinabove are for exemplary purposes and the UE 106 can establish the connection with the base station 102 based on any other conditions as well.

[0031] The UE 106 may establish the connection with the base station 102 via the communication network 108. It is understood that the UE 106 may be in operative communication with the communication network 108, such as the Internet, enabled by a network provider, also known as an Internet Service Provider (ISP). The UE 106 may be connected to the communication network 108 using a wireless network. Some non-limiting examples of wireless networks may include the Wireless LAN (WLAN), cellular networks, Bluetooth or ZigBee networks, and the like. In one embodiment, the network 108 may include or otherwise cover networks or subnetworks, each of which may include, for example, a wired or wireless data pathway.

[0032] Conventional wireless communication systems that employ Time Division Duplexing (TDD) are generally designed to be downlink-heavy. However, with the evolution of advanced applications, requirements for higher uplink capacity has grown substantially. To address such requirements, various approaches have been explored by the 3rd Generation Partnership Project (3 GPP). One such approach involves dynamically carving out a portion of spectrum or time-frequency resources traditionally reserved for downlink transmissions and making them available for uplink operation. More specifically, Sub-Band non-overlapping Full Duplex (SBFD) has been studied in 3GPP Release-18 as a technique to achieve this goal at the base station side within a conventional TDD band. Under the SBFD concept, a small and dedicated uplink frequency subband is carved out of the downlink slots. This dedicated uplink portion is referred to as the uplink sub-band that enables simultaneous downlink and uplink operations within the same TDD slots without overlapping in frequency. Examples of such configurations are illustrated in FIG. 2A-2C.

[0033] Reference is now made to FIG. 2A-2C, which illustrate exemplary configurations 200 of various wireless communication frames. FIG. 2A-2C depict a series of Downlink (DL) and Uplink (UE) slots arranged in various configurations represented as {DU} which is shown in FIG. 2A, {UD} which is shown in FIG. 2B, and {DUD} which is shown in FIG. 2C within the wireless communication frames. Specifically, {DU}, {UD} and {DUD} refer to configurations that facilitate both uplink and downlink communications within the same slot, highlighting a flexible structure for accommodating different types of data transmission.

[0034] In the above configurations of wireless communication frames, radio resources that are made available for uplink transmissions in an uplink sub-band are commonly referred to as uplink- usable Physical Resource Blocks (PRBs). Conversely, radio resources that are made available for downlink transmissions in a downlink sub-band are referred to as downlink-usable PRBs. The time-frequency structure of the TDD frame may therefore be viewed as comprising three general types of slot configurations: DL slots in which only downlink transmissions are scheduled, UL slots in which only uplink transmissions are scheduled, and SBFD or mixed slots (hereinafter referred to as “SBFD / FD slots”) in which a portion of radio resources is used for downlink transmissions while a carved-out portion may be designated for uplink transmissions.

[0035] In SBFD configuration, as a portion of the downlink radio resources is available in the form a small uplink sub-band, the UE 106 requires a mechanism to request uplink resources for communication within these SBFD slots. In 5G New Radio (NR), such requests are made through the RACH procedure which allows the UE 106 to send a short signal called a preamble to request uplink resources. Random access or RACH Occasions (ROs) (e.g., the specific time-frequencyopportunities when the UE 106 can send such a preamble) should now also be created inside the SBFD slots, and not just in the conventional UL slots.

[0036] There are two ways to create the new ROs inside the SBFD slots. In one example, the base station 102 may select an appropriate PRACH Configuration Index (PCI) (as defined in the 3GPP TS 38.211) so that ROs occur in both SBFD slots and UL slots. In another example, the base station 102 may define an additional RACH configuration that is exclusively for SBFD slots. However, the existing RACH configurations were originally designed only for normal TDD uplink slots. For example, in Frequency Range-1 (FR1) and unpaired spectrum, RACH configurations (e.g., as specified in Table 6.3.3.2-3 of 3GPP TS 38.211), are designed to address uplink slots of TDD. Similarly, for Frequency Range-2 (FR2), the RACH configurations (e.g., as specified in Table 6.3.3.2-4 of 3GPP TS 38.211) are also designed to address uplink slots of TDD. When a new PRACH configuration index is selected (whether it is common to both SBFD and normal UL slots or dedicated exclusively to SBFD / FD) it may unintentionally create unnecessary / unwanted RACH occasions. The unwanted ROs may appear in conventional UL slots or in SBFD / FD slots where they are not needed. Such unwanted ROs consume uplink resources that could otherwise carry actual uplink user data, thereby reducing the uplink throughput. Moreover, when uplink traffic is relatively low, it is desirable for the base station 102 have the flexibility of dynamically suppressing or deactivating certain unwanted ROs so that uplink resources are not wasted.

[0037] By way of illustration, reference is now made to FIG. 3, which illustrates a PRACH configuration table 300 having various PRACH configurations, in accordance with some embodiments of the present disclosure. In the PRACH configuration table 300, each entry comprises specific elements that are crucial for defining the PRACH configurations. These elements include a PRACH Configuration Index (PCI), a preamble format such as B4, and various parameters associated with each PCI including subframe numbers (e.g., 0, 1, 2, 3, 4, etc.), a starting symbol, a PRACH duration, a number of PRACH slots allocated within a subframe, and a number of time-domain PRACH occasions present in each PRACH slot. The PCI entries are populated based on TDD configuration. It may be noted from FIG. 3 that subframes 2, 4, 7, and 9 are most used subframes for RACH occasions. It may be noted that additional RACH configurations are one of the options to allocate new RO in SBFD slots. In RANI meetings, it was proposed thatadditional ROs created in non-SBFD slots by additional RACH configurations are invalid. In other words, the ROs created in the SBFD slots are considered as valid.

[0038] Consider, for purposes of illustration and without limitation, an example Random Access Channel (RACH) frame 400 having a duration of 10ms, as shown in FIG. 4. In this example, the RACH frame is divided into 10 subframes (indexed from 0 to 9), each subframe comprising a single slot based on a selected numerology. It will be appreciated by persons skilled in the art that this frame configuration is presented merely as an example and is not intended to limit the scope of the present disclosure. Other frame durations or slot structures may likewise be used depending on network design and numerology parameters.

[0039] Within such RACH frame 400, suppose that the PRACH Configuration Index (PCI) selected by the base station 102 is PCI 154, as shown in FIG. 4. The selection of PCI 154 defines RACH Occasions (i.e., specific time-frequency resources) during which the UE 106 may transmit a random access preamble. As per PRACH configurations defined in FIG. 3, the RACH occasions are defined slots 2, 3, 4, 7, 8, and 9 of the RACH frame 400. In FIG. 4, different symbols are used to identify the type of resources in each slot of the RACH frame. The symbol ‘U’ represents UL slot dedicated only to transmissions from the UE 106 to the base station 102. The symbol ‘D’ represents a DL slot reserved for transmissions from the base station 102 to the UE 106. The symbol ‘X’ represents a mixed slot which contains both uplink and downlink resources in different portions of the slot. The SBFD slots are created specifically within these ‘X’ slots, by carving out a small portion of downlink spectrum to support uplink transmissions.

[0040] The RACH occasions are defined in slots 2, 3, 4, 7, 8, and 9 of the RACH frame 400. There are different types of RACH occasions (ROs) created when the base station 102 uses the PCI 154. In slots 2 and 7, there are already existing legacy uplink slots that have enough ROs for random access. The extra RACH occasions created by PCI 154 in these slots do not add any benefit and therefore are unwanted or unnecessary (referred to as “additional unwanted RACH occasions in uplink slots” or “RO-3”). In slots 4 and 9, the base station 102 prefers to use the available uplink resources for user data transmission in the SBFD slots. But when PCI 154 creates new RACH occasions in slots 4 and 9, the RACH occasions in these slots compete with uplink data traffic,taking up valuable spectrum that would otherwise be used to carry actual user data. Such RACH occasions are also not needed and are referred to as “unwanted RACH occasions in specific slots” or “RO-2”. On the other hand, the RACH occasions in slots 3 and 8 are necessary because these RACH occasions provide legitimate opportunities for the UE 106 to perform random access. These are known as “wanted ROs in specific slots” or “RO-1”. The wanted RACH occasions (RO-1) may also be referred to as “valid RACH occasions” and the unwanted RACH occasions (RO-2, RP-3) may also be referred to as “invalid RACH occasions.”

[0041] In existing systems, all RACH occasions in the SBFD slots are treated as valid and are signaled to the UE 106 without any filtering. However, not every the SBFD slots needs to have RACH occasions in all types of deployments. The number of RACH occasions needed or the number of SBFD slots needed for RACH occasions may depend on network conditions such as an amount of uplink traffic, a number of active UEs, or a desired quality of service, etc. Unnecessary RACH occasions, which are created and signaled to the UE, may have adverse effects including consumption of uplink resources that could otherwise be allocated to actual user data transmission, reduction in effective uplink throughput as resources that could carry user data are instead reserved for unnecessary RACH occasions, and inefficient spectrum utilization especially in scenarios where uplink traffic demands are high.

[0042] Therefore, there is a need for techniques to selectively invalidate or disable signaling of unwanted RACH occasions and indicate wanted RACH occasions to the UE 106, thereby freeing up more uplink resources for user traffic and improving uplink throughput, specifically in SBFD slots. The present disclosure discloses selecting, from the PRACH configuration table, a PRACH Configuration Index (PCI) that provides a plurality of RACH occasions in a first type of slots (e.g., SBFD slots) within a RACH frame. The RACH occasions are then categorized into wanted and unwanted occasions. A bitmap is generated, marking wanted RACH occasions (or valid RACH occasions) with a first logical value and unwanted RACH occasions (or invalid RACH occasions) with a second logical value. The method further checks if the bitmap shows a repetition pattern. If a repetition is found, a compressed bitmap is created to represent only the repeating portion, and a repeat indicator is appended to show whether this pattern should continue until the end of the frame. The base station then transmits the compressed bitmap and the repeat indicator to one ormore User Equipment (UEs), enabling the UEs to perform random access only during the indicated wanted RACH occasions.

[0043] FIG. 5 discloses a method 500 of generating and transmitting a bitmap for RACH occasions. The method 500 discloses providing only wanted RACH occasions in SBFD slots and invalidating all the unwanted RACH occasions that are set by a PCI mentioned in random access configurations tables for both FR1 (paired and unpaired) and FR2 in 3GPP TS 28.211.

[0044] The RACH Occasions (defined by the PCI) indicate configurations which tell the UE 106 when and where the UE 106 is allowed to send a RACH preamble in order to start communication with the base station 102. The RACH occasions are normally provided by the base station 102 either in the System Information Block Type 1 (SIB1) or through Radio Resource Control (RRC) configuration / reconfiguration message. When the UE 106 decodes the SIB1 or receives the RRC configuration / reconfiguration message, the UE 106 learns the full set of possible RACH occasions across the entire RACH frame. The RACH occasions are periodically repeated so that the UE 106 can attempt random access at the defined intervals. In an embodiment, all RACH occasions start from the beginning of the RACH frame, i.e., sub-frame 0 or slot 0.

[0045] At operation 502, the base station 102 (or a scheduler of the base station 102) may decide when and where the base station 102 wants certain UEs to send RACH preambles or where the base station 102 intends to create desired or wanted RACH occasions. To do this, the base station 102 selects one or more specific SBFD slots within the RACH frame where the RACH occasions should occur. The base station 102 may then corelate the selected SBFD slots with the PRACH configuration table (shown in FIG. 3). This table lists many PRACH Configuration Indexes (PCIs), each PCI defining exactly which slots (or subframes) of the RACH frame contains RACH occasions. The base station 102 scans through the table and identifies candidate PRACH Configuration Indexes (PCIs) having the selected SBFD slots.

[0046] For example, consider that the base station 102 decides to schedule random access (or to have RACH occasions) in slots 3 and 7 of the RACH frame, both of which are SBFD slots. From FIG. 3, the PCIs that include RACH occasions in both slots 3 and 7 are: PCI 154 (having RACHoccasions in slots 2, 3, 4, 7, 8, 9), PCI 166 (having RACH occasions in slots 1, 3, 5, 7, 9), PCI 167 (having RACH occasions in all slots 0-9), and PCI 168 (having RACH occasions in all slots 0-9). Each of these PCIs includes the desired SBFD slots 3 and 7, but they also have extra, unwanted RACH occasions in other slots. At operation 502, the base station 102 simply selects one PCI that provides RACH occasions at least in the specified SBFD slots.

[0047] At operation 504, the base station 102 may determine whether the selected PCI comprises minimum / least number of unwanted RACH occasions among the candidate PCIs. If the base station 102 determines that the selected PCI comprises least number of unwanted RACH occasions, the base station 102 proceeds at operation 508. On the other hand, if the base station 102 determines that the selected PCI does not comprise least number of unwanted RACH occasions, the base station 102 may select another PCI at operation 506 and then proceed to operation 502. In operations 502-506, the base station is selecting a PCI that minimizes the number of the unwanted RACH occasions.

[0048] Specifically, the base station 102 may compare the selected PCI with remaining candidate PCIs identified in operation 502 to determine the one PCI with least number of unwanted RACH occasions. For example, the base station determines that the PCI 154 has unwanted RACH occasions in slots 2, 4, 8, 9 (i.e., 4 slots), PCI 166 has unwanted ROs in slots 1, 5, 9 (i.e., 3 slots), PCI 167 has unwanted ROs in 8 slots, and PCI 168 also has unwanted RACH occasions in 8 slots. At the end of operations 502, 504, 506, the base station 102 selects the one PCI which has least number of unwanted RACH occasions. For example, the among the candidate PCIs 154, 166, 167, 168, the PCI 166 is having the least number of unwanted RACH occasions or least number of slots with unwanted RACH occasions. Thus, the PCI 166 is selected as having the least number of unwanted RACH occasions.

[0049] In another example, if the base station 102 decides to provide RACH occasions in SBFD slots 3, 7, and 8 of the RACH frame. The base station 102 may parse through the PRACH configuration table to find candidate PCIs that contain RACH occasions in all selected slots 3, 7, and 8. From the table, the candidate PCIs that satisfy this requirement are 154, 167, and 168. The base station 102 may compare these PCIs and selects the PCI with the fewest unwanted RACHoccasions while still covering the required slots. In this case, PCI 154 has only three unwanted RACH occasions, which is less than the seven unwanted occasions of PCI 167 or PCI 168. Therefore, when the base station 102 needs RACH occasions specifically in SBFD slots 3, 7, and 8, the base station may select PCI 154.

[0050] It may be noted that every PRACH Configuration Index (PCI) defines a pattern of RACH occasions that can occur in different slots of the RACH frame. These slots can belong to two categories: SBFD slots (where the base station may allow simultaneous uplink and downlink transmissions) and non-SBFD slots (ordinary TDD slots). For example, according to the PRACH configuration table, the PCI 154 is configured to support RACH occasions in slots 2, 3, 4, 7, 8, and 9 of each RACH frame. Among these slots, slots 3, 4, 8, and 9 are identified as SBFD slots and slots 2 and 7 are identified as non-SBFD slots. Further, among the SBFD slots, the base station 102 is selecting some slots for providing the RACH occasions.

[0051] At operation 508, after selecting the PCI that minimizes unwanted RACH occasions, the base station 102 may analyze all RACH occasions defined by the PCI. Specifically, the base station 102 scans the list of slots defined by the PCI and checks if any RACH occasions fall in non-SBFD slots (such as ordinary TDD uplink slots where random access is not desired). If no such RACH occasions are identified (e.g., when all the RACH occasions of the selected PCI are already inside SBFD slots), the base station proceeds to bitmap generation at operation 512. However, if the base station 102 identifies RACH occasions falling in non-SBFD slots (e.g., uplink slots) that are unintended for random access, the base station 102 proceeds at operation 510.

[0052] At operation 510, when the base station 102 identifies RACH occasions falling in non- SBFD slots (e.g., uplink slots) that are unintended for random access, the base station 102 excludes the identified RACH occasions falling in non-SBFD slots from the bitmap generation. Specifically, the base station may mark these RACH occasions as invalid. These excluded slots are not represented in the bitmap that is generated next. This filtering step prevents UEs from wasting power by attempting random access in slots that the base station does not intend to monitor.

[0053] At operation 512, the base station 102 categories the plurality of RACH occasions falling in the SBFD slots into wanted RACH occasions and unwanted RACH occasions. Specifically, any RACH occasions that fall in the SBFD slots (which are selected by the base station for supporting random access) are considered wanted RACH occasions, because these are the occasions that the base station 102 intends the UE 106 to use for sending preambles. On the other hand, the RACH occasions that fall in SBFD slots that are not selected by the base station 102 are considered unwanted RACH occasions, since they are unnecessary and could potentially waste uplink resources. Considering PCI 154, if the slots 3 and 8 are selected by the base station for providing RACH occasions then the RACH occasions falling in slots 3 and 8 are categorized as wanted RACH occasions. The remaining SBFD slots defined by the PCI (i.e., 4 and 9) are not selected by the base station 102 for random access and the RACH occasions falling in these unselected SBFD slots are categorized as unwanted RACH occasions.

[0054] At operation 512, the base station 102 may then generate a bitmap in which the SBFD slots having the wanted RACH occasions are represented by a first logical value and SBFD slots having the unwanted RACH occasions are represented by a second logical value. In one example, the first logical value may be “1” and the second logical value may be “0”. For instance, consider PCI 154 with four SBFD slots in a RACH frame, indexed as 3, 4, 8, and 9. If the base station 102 selects slots 3 and 8 as the slots where RACH occasions are needed, the bitmap would be 1010. Here, the first “1” represents that slot 3 has a wanted RACH occasion, the first “0” indicates that slot 4 has an unwanted RACH occasion (or no RO), the second “1” indicates that slot 8 has a wanted RACH occasion, and the final “0” indicates that slot 9 has an unwanted RACH occasion (or no RACH occasion). In another example, if the base station 102 selects slots 3, 8, and 9 as having wanted ROs, the bitmap would be 1011. In this case, slots 3, 8, and 9 are indicated as wanted ROs with a value of “1,” while slot 4 remains “0,” indicating an unwanted RACH occasion or no RACH occasion that the UE 106 should ignore.

[0055] At block 514, the base station 102 may identify whether the generated bitmap exhibits a repetition pattern of the wanted and unwanted RACH occasions within the RACH frame. Identifying such a pattern helps to compress the bitmap and transmit the RACH occasions more efficiently to the UE 106. For instance, suppose the base station 102 selects slots 3 and 8 of PCI154 as the slots where RACH occasions are needed. The resulting bitmap is 1010, representing four SBFD slots in the RACH frame. In this case, the bitmap shows a clear repetition pattern of “10”, which means that the bit pattern repeats across the RACH frame. In another example, if the base station 102 selects slots 3, 8, and 9 of the PCI 154 as the slots for wanted RACH occasions, the bitmap becomes 1011. In this case, there is no repeating pattern, because the arrangement of wanted and unwanted RACH occasions does not repeat consistently across the RACH frame.

[0056] At block 516, upon identifying the repetition pattern within the generated bitmap, the base station 102 may generate a compressed bitmap corresponding to a portion of the bitmap that defines the repetition pattern. The base station 102 may append a repeat indicator with the compressed bitmap indicating to the UEs 106 whether the compressed portion of the bitmap is to be repeated until an end of the RACH frame. It may be noted that the compressed bitmap may be referred to as “a compressed RACH occasion indicator”.

[0057] At block 518, the base station transmits the compressed bitmap along with the repeat indicator to the one or more UEs for performing random access during the wanted RACH occasions indicated in the compressed bitmap. Further, if the base station 102 identifies that there is no repetition pattern within the generated bitmap, the base station 102 may transmit the generated bitmap to the one or more UEs for performing random access during the wanted RACH occasions indicated in the compressed bitmap. The bitmap or the compressed bitmap along with the repeat indicator may be transmitted in at least one of: a System Information Block 1 (SIB1) message, a Radio Resource Control (RRC) configuration message, or an RRC reconfiguration message.

[0058] It may be noted that process of signaling RACH occasions to the UEs 106, the repeat indicator (RI) plays an important role in efficiently compressing and transmitting the bitmap. The RI can be either the least significant bit (LSB) or the most significant bit (MSB) of the bitmap byte, and carries a logical value, typically ‘0’ or ‘1’, which tells the UEs 106 how to interpret the bitmap. Specifically, the repeat indicator (RI) indicates or informs the UEs 106 about at least one of (i) whether the compressed bitmap is to be repeated until the end of the RACH frame, and (ii)whether an additional byte of bitmap information is to be accessed to identify the wanted RACH occasions.

[0059] In many cases, one byte of bitmap is sufficient to indicate all the wanted and unwanted ROs for the SBFD slots. However, in scenarios with higher subframe or slot counts (such as in Frequency Range 2 (FR2)) two bytes may be required to represent all the necessary RACH occasions. The logical value “0” of the repeat indicator indicates that the current bitmap byte contains a complete bit pattern (there is no next byte to read), and the bit pattern should be repeated until the end of the RACH frame. The logical value “1” of the repeat indicator indicates that the current bitmap byte is not the complete bit pattern and an additional bitmap byte is present which contains additional bitmap information for other RACH occasions. When multiple bitmap bytes are used, the UE 106 may combine the bitmaps from all bytes before applying the repetition.

[0060] In this way, the base station may transmit a compressed bitmap indicating wanted and unwanted RACH occasions efficiently, without sending the full bitmap for the entire RACH frame. In one example, the repetition of the bit pattern may be allowed only when the number of SBFD slots with the RACH frame is an integer multiple of the bitmap size (excluding the repeat indicator). Such constraints ensure that bit pattern aligns perfectly with the frame structure and covers all the intended slots or subframes. In certain scenarios, the base station 102 may apply the bitmap compression techniques when a utilization of the uplink sub-band crosses a predefined threshold value.

[0061] At the UE side, the UE 106 receives the compressed bitmap along with the repeat indicator from the base station 102. The compresses bitmap and the repeat indicator may come through SIB1, an RRC configuration, or an RRC reconfiguration message. The compressed bitmap contains a shortened representation of the wanted and unwanted RACH occasions, and the repeat indicator indicates whether the compressed portion should be repeated for the rest of the RACH frame or whether additional bitmap bytes need to be read.

[0062] Once the UE receives the compressed bitmap, the UE 106 decodes the compressed bitmap according to the repeat indicator to obtain an expanded bitmap representing RACH occasionsduring which random access is permited. If the UE 106 identifies the repeat indicator as “0”, the UE determines that the current bitmap patern should be cyclically repeated for the remainder of the RACH frame. If the UE identifies the repeat indicator as “1”, the UE 106 checks for the next byte of bitmap information, combines the next byte bitmap with the current bitmap, and then checks the repeat indicator of the second byte to determine whether the combined patern should be cyclically repeated. In this manner, the UE 106 reconstruct full bitmap of SBFD slots containing wanted ROs and unwanted ROs. In some cases, decoding the bitmap comprises cyclically repeating a portion of the bitmap until the expanded bitmap covers the entire RACH frame.

[0063] After decoding and expanding the bitmap, the UE 106 performs random access during the wanted RACH occasions. Specifically, the UE 106 identifies exact slots / subframes where the UE 106 is allowed to send RACH preamble. The UE 106 then performs random access transmissions only in the indicated ROs, avoiding slots that are unwanted or reserved for uplink data, as indicated in the bitmap.

[0064] In this manner, the proposed techniques allow each UE to monitor only wanted RACH occasions rather than having to monitor and process every single RO signaled by the base station 102. The proposed techniques avoids blind decoding of unused RO occasions at the UE 106. Therefore, the proposed techniques significantly reduce the amount of signal processing and unwanted RACH transmissions at the UE 106, which in turn leads to lower power consumption and longer batery life of the UE 106.

[0065] In some aspects, the base station 102 may first check whether the UE 106 is capable of handling the compressed bitmap-based RACH occasion signaling. To enable this, the UE 106 may send a capability indication to the base station, for example, as part of its capability exchange procedure during registration or RRC setup. The indication indicates to the base station 102 whether the UE 106 supports the mechanism for compressed bitmap decoding and repeat indicator interpretation.

[0066] Examples of bitmap generation:

[0067] FIG. 6A and 6B show various examples of bitmaps. As shown in FIG. 6A, suppose the base station 102 selects PCI 154 having four SBFD slots in a RACH frame 400. The four SBFDslots are indexed as 3, 4, 8, and 9. If the base station 102 selects slots 3 and 8 as the slots where ROs are needed, the bitmap would be 1010. In this case, the bitmap shows a clear repetition of bit pattern “10”, which means that the bit pattern “10” repeats across the RACH frame 400. The base station 102 then generates a compressed bitmap and appends a repeat indicator. The compressed bitmap with repeat indicator is: 10| 0 (as shown in FIG. 6A).

[0068] In another example, if the base station 102 selects slots 3, 8, and 9 of the PCI 154 as the slots for wanted ROs, the bitmap becomes 1011. In this case, there is no repeating pattern, because the arrangement of wanted and unwanted ROs does not repeat consistently within the RACH frame. Thus, the base station 102 may transmit the generated bitmap “1011” without compression to the UE(s), as shown in FIG 6B.

[0069] Bitmap within single byte example:Bitmap = 10|0: The bit pattern‘10’ represents the wanted and unwanted ROs, and the RI ‘0’ indicates there is no next byte and that this bitmap pattern ‘10’ should repeat until the end of the RACH frame.

[0070] Bitmap extending beyond single byte example:First byte = 10100| 1 : The RI ‘ 1 ’ indicates there is another byte (or second byte) to read.Second byte = 10010|0: The RI ‘0’ indicates this is the last byte, and the combined bitmap (first + second byte = 1010010010|0) should be repeated until the end of the RACH frame (provided the number of SBFD slots in the RACH frame is multiple of the bitmap size i.e., 10).

[0071] In this manner, the present disclosure discloses techniques for efficiently indicating RACH occasions in a wireless communication system using a bitmap, wherein the bitmap is a compressed RACH occasion indicator. The bitmap provides a compact representation of the specific RACH occasions that are configured by the base station. Traditionally, all RACH occasions configured through a PRACH Configuration Index (PCI) are treated as valid and are transmitted to the UE. However, not every RACH occasion is required at all times, particularly in scenarios where UL traffic is low, where the Quality of Service (QoS) priority changes, or where network resources need to be optimized to maximize uplink throughput.

[0072] In some examples, the base station 102 may select the SBFD slots based on uplink traffic load, QoS priority, etc. and accordingly the bitmap generation may be dynamically adapted based on the uplink traffic load, the QoS priority, etc. For example, if the uplink traffic is low, then fewer RACH occasions may be signaled in the bitmap and if the uplink traffic is high, then more RACH occasions may be signaled in the bitmap. Such dynamic adaptation of the RACH occasions may be indicated via Downlink Control Information (DCI) with reduced overhead of signaling. Further, it may be noted that the transmission of the bitmap avoids signaling overhead particularly beneficial during frequent handovers, where minimizing signaling overhead is critical to maintaining seamless connectivity.

[0073] To enhance robustness, the disclosure provides a fail-safe fallback procedure. In this procedure, if the UE 106 does not receive a fresh bitmap update before the expiry of a predetermined threshold time, the UE 106 may automatically fall back to a legacy minimal map that is pre-embedded in SIB1. This ensures that the UE always has at least a basic set of valid RACH occasions to attempt random access, even in case of temporary signaling failures.

[0074] The proposed techniques may also be applicable to non-terrestrial networks (NTN), such as satellite-based communication systems or the communication system may comprise the NTN. In this embodiment, the base station 102 may identify wanted RACH occasions falling within a predefined visibility window determined based on ephemeris information and generate the bitmap based on the wanted RACH occasions falling within the predefined visibility window such that the bitmap represents ephemeris -gated RACH occasions. More specifically, in the NTN, RACH preamble transmissions are usually configured to occur on all network-indicated RACH occasions. However, many of these occasions may fall outside a satellite’s or a cell’s visibility window and hence, the UE 106 may not communicate with the satellite at those times. To address this inefficiency, the present disclosure introduces “ephemeris -gated” bitmaps. Such bitmaps use satellite ephemeris information to identify valid visibility windows, and encodes only those RACH occasions that fall within the visibility windows as valid. As a result, uplink transmissions are restricted to valid RACH occasions that align with the satellite’s actual coverage area, thereby avoiding unnecessary transmission attempts and improving uplink resource utilization.

[0075] In certain cases, the techniques of the present disclosure may be used for 6G wireless communication systems where the bitmap may be used to differentiate between different device and / or service type. For example, Ultra-Reliable Low-Latency Communications (URLLC) services typically require fast and reliable network access compared to Enhanced Mobile Broadband (eMBB) services that are less delay-sensitive but require high data throughput. In such cases, the base station 102 generates bitmap having RACH occasions valid / wanted for one service type (e.g., URLLC) and invalid / unwanted for another service type (e.g., eMBB). Thus, different device types and / or different service types may be indicated using the bitmap.

[0076] More generally, the communication system may support a plurality of service types (e.g., eMBB, URLLC, etc.), each with distinct QoS requirements. The base station 102 may select which RACH occasions should be marked as valid / wanted based on the specific service type. Thus, the wanted RACH occasions in the bitmap correspond to at least one first service type (e.g., wanted service type such as URLLC) of the plurality of service types that requires random access, and the unwanted RACH occasions correspond to at least one second service type (e.g., unwanted service type such as eMBB) of the plurality of service types for which random access is not required. The service type information that determines how the bitmap is configured may be indicated to the UE 106 through existing control mechanisms such as a Downlink Control Information (DCI) message or a Radio Resource Control (RRC) configuration / reconfiguration message. In this manner, both the base station 102 and the UEs 106 know which RACH occasions are valid / wanted for a given service type, thereby enabling efficient use of uplink resources while still meeting the QoS requirements of different service types.

[0077] In certain deployments, wanted RACH occasions may change slowly across consecutive RACH frames. In such deployments, to further reduce control signaling, the base station 102 may employ a delta-based bitmap signaling technique. In this technique, instead of transmitting a full compressed bitmap during every update, the base station 102 may send only the differences (deltas) relative to a previously broadcasted compressed bitmap (which may also be referred to as a “reference map”). This delta-based approach may further reduce the signaling overhead while maintaining the accuracy of the indicated RACH occasions. To distinguish between a fullcompressed bitmap and a delta bitmap, the base station 102 may include a Delta Type Indicator (DU) along with the bitmap. The DTI is a single-bit logical value. In one example, DU: 0 indicates that the transmitted bitmap is a full compressed bitmap. DTI: 1 indicates that the transmitted bitmap is a delta bitmap. Upon receiving the delta bitmap, the UE may update the reference bitmap by applying the changes indicated in the delta bitmap. If the DU indicates a full compressed bitmap, the UE 106 replaces the reference bitmap entirely with the newly received bitmap. The base station 102 may also keep updating the reference bitmap.

[0078] The proposed techniques provide a way for the base station 102 to share only the necessary RACH occasions with the UE in SBFD slots, while automatically ignoring or invalidating any extra RACH occasions that would normally be created by the PRACH Configuration Index (PCI) as defined in the 3 GPP TS 38.211 specification. This approach ensures that only the expected or needed RACH occasions are used, which helps saving uplink resources and improving uplink data throughput.

[0079] FIG. 7 illustrates a flow chart of an exemplary method 700 of wireless communication within a communication system. The method 700 may be performed at a base station 102 for optimizing RACH occasions.

[0080] At block 702, the method 700 may include selecting, from a PRACH configuration table, a PRACH Configuration Index (PCI) that provides a plurality of RACH occasions in a first type of slots within a RACH frame. At block 704, the method 700 may include categorizing the plurality of RACH occasions into wanted RACH occasions and unwanted RACH occasions. At block 706, the method 700 may include generating a bitmap in which slots having the wanted RACH occasions are represented by a first logical value and slots having the unwanted RACH occasions are represented by a second logical value. At block 708, the method 700 may include identifying whether the generated bitmap exhibits a repetition pattern of the wanted and unwanted RACH occasions within the RACH frame.

[0081] At block 710, the method 700 may include generating a compressed bitmap corresponding to a portion of the bitmap that defines the repetition pattern and appending a repeat indicator withthe compressed bitmap, upon identifying the repetition pattern within the generated bitmap. The repeat indicator indicating whether the compressed bitmap is to be repeated until an end of the RACH frame. At block 712, the method 700 may include transmitting the compressed bitmap along with the repeat indicator to one or more UEs for performing random access during the wanted RACH occasions indicated in the compressed bitmap

[0082] FIG. 8 illustrates a flow chart of an exemplary method 800 of wireless communication within a communication system. The method 800 may be performed at a UE 106 for performing random access by transmitting RACH preambles.

[0083] At block 802, the method 800 may include receiving, from a base station, a bitmap along with a repeat indicator, the repeat indicator indicating whether the bitmap is to be repeated until an end of a Random- Access Channel (RACH) frame. At block 804, the method 800 may include decoding the bitmap according to the repeat indicator to obtain an expanded bitmap representing RACH occasions during which random access is permitted. At block 806, the method 800 may include performing random access during the RACH occasions.

[0084] The above methods 700 and 800 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types.

[0085] The various blocks of the methods 700 and 800 shown in Figures 7-8 have been arranged in a generally sequential manner for ease of explanation. However, it is to be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with methods 700 and 800 (and the blocks shown in Figures 7-8) may occur in a different order (for example, where at least some of the processing associated with the blocks is performed in parallel and / or in an event-driven manner). Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof.

[0086] The various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and / or software component(s) and / or module(s). Generally, where there are operations illustrated in Figures, those operations may have corresponding counterpart means-plus-function components. It may be noted here that the subject matter of some or all embodiments described with reference to Figures 1-6 may be relevant for the methods and the same is not repeated for the sake of brevity.

[0087] Referring now to, FIG. 9 which shows a high-level block diagram of an apparatus 900, in accordance with some embodiments of the present disclosure. The apparatus 900 may comprise at least one transmitter 902, at least one receiver 904, at least one processor 908, at least one memory 910, at least one interface 912, and at least one antenna 914. In one embodiment, the at least one transmitter 902 may be configured to wirelessly transmit data / information to one or more nodes / devices / units using the antenna 914 and the at least one receiver 904 may be configured to wirelessly receive data / information from the one or more nodes / devices using the antenna 914. The at least one transmitter and receiver may be collectively implemented as a single transceiver module 906. In one non-limiting embodiment, the at least one processor 908 may be communicatively coupled with the transceiver 906, memory 910, interface 912, and antenna 914.

[0088] The at least one processor 908 may include, but not restricted to, microprocessors, microcomputers, micro-controllers, central processing units, state machines, logic circuitries, and / or any devices that manipulate signals based on operational instructions. A processor may also be implemented as a combination of computing devices, e.g., a combination of a plurality of microprocessors or any other such configuration. The at least one memory 910 may be communicatively coupled to the at least one processor 908 and may comprise various instructions, information related to configuration of the repeater system and / or the at least one base station etc. The at least one memory 910 may include a Random-Access Memory (RAM) unit and / or a nonvolatile memory unit such as a Read Only Memory (ROM), optical disc drive, magnetic disc drive, flash memory, Electrically Erasable Read Only Memory (EEPROM), a memory space on a server or cloud and so forth. The at least one processor 908 may be configured to execute one or more instructions stored in the memory 910.

[0089] The interfaces 912 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, an input device-output device (I / O) interface, a network interface, and the like. The I / O interfaces may allow the apparatus 900 to communicate with one or more nodes / units / devices either directly or through other devices. The network interface may allow the apparatus 900 to interact with one or more networks either directly or via any other network.

[0090] In one non-limiting embodiment, the apparatus 900 may be any of: a user equipment 106, a base station 102, but not limited thereto. In one non-limiting embodiment, the disclosed method performed at the base station 102 and the UE 106 may be implemented with the help of the apparatus 900, where the processor 908 in conjunction with the transceiver 906, memory 910, interface 912, and antenna 914 may be configured to implement the proposed techniques.

[0091] In a non-limiting embodiment of the present disclosure, one or more non-transitory computer-readable media may be utilized for implementing the embodiments consistent with the present disclosure. Certain non-limiting embodiments may comprise a computer program product for performing the operations presented herein. For example, such a computer program product may comprise a computer readable media having instructions stored (and / or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein.

[0092] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the disclosure be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present disclosure are intended to be illustrative, but not limiting, of the scope of the disclosure, which is set forth in the appended claims.

Claims

WE CLAIM:

1. A method of wireless communication within a communication system, the method comprising: selecting, from a Physical Random-Access Channel (PRACH) configuration table, a PRACH Configuration Index (PCI) that provides a plurality of RACH occasions in a first type of slots within a RACH frame; categorizing the plurality of RACH occasions into wanted RACH occasions and unwanted RACH occasions; generating a bitmap in which slots having the wanted RACH occasions are represented by a first logical value and slots having the unwanted RACH occasions are represented by a second logical value; identifying whether the generated bitmap exhibits a repetition pattern of the wanted and unwanted RACH occasions within the RACH frame; and upon identifying the repetition pattern within the generated bitmap: generating a compressed bitmap corresponding to a portion of the bitmap that defines the repetition pattern and appending a repeat indicator with the compressed bitmap, the repeat indicator indicating whether the compressed bitmap is to be repeated until an end of the RACH frame; and transmitting the compressed bitmap along with the repeat indicator to one or more User Equipment (UEs) for performing random access during the wanted RACH occasions indicated in the compressed bitmap.

2. The method of claim 1, further comprising: before categorizing the plurality of RACH occasions into the wanted RACH occasions and the unwanted RACH occasions, identifying RACH occasions falling in uplink slots that are unintended for random access and excluding the identified RACH occasions from the bitmap generation.

3. The method of claim 1, wherein the bitmap is a compressed RACH occasion indicator, and wherein the repeat indicator comprises a logical value indicating at least one of (i) whether thecompressed bitmap is to be repeated until the end of the RACH frame, and (ii) whether an additional byte of bitmap information is to be accessed to identify the wanted RACH occasions.

4. The method of claim 1, wherein the communication system supports sub-band full-duplex (SBFD) or full-duplex (FD) operations, and the first type of slots within the RACH frame correspond to slots allocated for the SBFD or FD operations.

5. The method of claim 1, wherein the communication system comprises Non-Terrestrial Networks (NTN), and the method further comprising: identifying wanted RACH occasions falling within a predefined visibility window determined based on ephemeris information; and generating the bitmap based on the wanted RACH occasions falling within the predefined visibility window such that the bitmap represents ephemeris-gated RACH occasions.

6. The method of claim 1, wherein the communication system supports a plurality of service types with different Quality of Service (QoS) requirements, and wherein the plurality of RACH occasions indicated in the bitmap are selected based on a service type such that the wanted RACH occasions of the bitmap correspond to at least one first service type and the unwanted RACH occasions of the bitmap correspond to at lest one second service type of the plurality service types, the plurality of service types being indicated by at least one of a Downlink Control Information (DCI) message or a Radio Resource Control (RRC) message.

7. The method of claim 1, wherein transmitting the compressed bitmap comprises transmitting the compressed bitmap along with the repeat indicator in at least one of: a System Information Block 1 (SIB1) message, a Radio Resource Control (RRC) configuration message, or an RRC reconfiguration message.

8. The method of claim 1, wherein selecting the PCI comprises selecting the PCI that minimizes a number of the unwanted RACH occasions.

9. The method of claim 1, further comprising:upon identifying no repetition pattern within the generated bitmap, transmitting the generated bitmap to the one or more UEs for performing random access during the wanted RACH occasions indicated in the compressed bitmap.

10. A method of wireless communication within a communication system, the method comprising, the method comprising: receiving, from a base station, a bitmap along with a repeat indicator, the repeat indicator indicating whether the bitmap is to be repeated until an end of a Random- Access Channel (RACH) frame; decoding the bitmap according to the repeat indicator to obtain an expanded bitmap representing RACH occasions during which random access is permitted; and performing random access during the RACH occasions.

11. The method of claim 10, wherein the bitmap is a compressed RACH occasion indicator, and wherein the repeat indicator comprises a logical value indicating at least one of (i) whether the bitmap is to be repeated until the end of the RACH frame, and (ii) whether an additional byte of bitmap information is to be accessed to identify the wanted RACH occasions.

12. The method of claim 10, wherein the communication system supports sub-band full-duplex (SBFD) or full-duplex (FD) operations, and the wanted RACH occasions correspond to slots allocated for the SBFD or FD operations.

13. The method of claim 10, wherein decoding the bitmap comprises cyclically repeating a portion of the bitmap until the expanded bitmap covers the entire RACH frame.

14. The method of claim 10, wherein receiving the bitmap comprises receiving a compressed bitmap along with the repeat indicator in at least one of: a System Information Block 1 (SIB1) message, a Radio Resource Control (RRC) configuration message, or an RRC reconfiguration message.

15. A base station for wireless communication within a communication system, the base station comprising: a memory; and at least one processor coupled with the memory and configured to: select, from a Physical Random- Access Channel (PRACH) configuration table, a PRACH Configuration Index (PCI) that provides a plurality of RACH occasions in a first type of slots within a RACH frame; categorize the plurality of RACH occasions into wanted RACH occasions and unwanted RACH occasions; generate a bitmap in which slots having the wanted RACH occasions are represented by a first logical value and slots having the unwanted RACH occasions are represented by a second logical value; identify whether the generated bitmap exhibits a repetition pattern of the wanted and unwanted RACH occasions within the RACH frame; and upon identifying the repetition pattern within the generated bitmap: generate a compressed bitmap corresponding to a portion of the bitmap that defines the repetition pattern and appending a repeat indicator with the compressed bitmap, the repeat indicator indicating whether the compressed bitmap is to be repeated until an end of the RACH frame; and transmit the compressed bitmap along with the repeat indicator to one or more User Equipment (UEs) for performing random access during the wanted RACH occasions indicated in the compressed bitmap.

16. A User Equipment (UE) for wireless communication within a communication system, the UE comprising: a memory; and at least one processor coupled with the memory and configured to: receive, from a base station, a bitmap along with a repeat indicator, the repeat indicator indicating whether the bitmap is to be repeated until an end of a Random Access Channel (RACH) frame;decode the bitmap according to the repeat indicator to obtain an expanded bitmap representing wanted RACH occasions during which random access is permitted; and perform random access during the wanted RACH occasions.

Images