On-demand system information block type 1 (SIB1) control signaling

Abstract

This disclosure provides systems, methods, and apparatuses for a user equipment (UE) (102A) to request a system information block type 1 (SIB1) (180A) from a network entity (104A). To conserve energy, the network entity might refrain from sending one or more SIB 1s associated with one or more synchronization signal blocks (SSBs) (130A) in a cell. In accordance with this disclosure, the network entity may employ techniques that reduce the overhead incurred when responding to multiple SIB1 requests from multiple UEs. The techniques include configuring ROs and PRACH preambles that increase the probability that the network entity can transmit a single RAR and a single SIB1 in response to the multiple requests for the SIB1. The techniques further include the UE refraining from transmitting a PRACH when beam quality is low.

Description

ON-DEMAND SYSTEM INFORMATION BLOCK TYPE 1 (SIB1) CONTROL SIGNALINGTECHNICAL FIELD

[0001] This disclosure relates generally to wireless communication and some aspects relate to a user equipment (UE) request to receive a system information block type 1 (SIB1) from a network entity.

[0002] DESCRIPTION OF RELATED TECHNOLOGY

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] In a wireless communication system, a network entity (such as a base station) and a user equipment (UE) can implement techniques to reduce power consumption. For example, a UE operates in a radio resource control (RRC) connected state when the UE has an active wireless connection with a network entity. During times when the UE does not have an active wireless connection with the network entity, the UE can enter a power saving mode. For example, the UE transitions from the RRC connected state to an RRC idle state or RRC inactive state. In the RRC idle state, the UE releases the RRC configuration. In the RRC inactive state, the UE suspends the RRC configuration and the RRC configuration can remain dormant until the UE transitions back to the RRC connected state. During the RRC idle or inactive states, the UE can obtain downlink synchronization signals (e.g., synchronization signal blocks (SSBs) ) and system information (SI) from the network entity, for example, via a system information block type 1 (SIB1) . The UE relies on SI from the network entity for various operations, such as cell selection (e.g., at power on) , cell-reselection, return from out of coverage, performing a random access procedure, and transitioning to RRC connected state, among other examples.

[0005] It is desirable to reduce signaling overhead and improve network energy performance. Some recent improvements to wireless communication technology are based on network energy saving (NES) in which the network entity eliminates or reduces some uplink and downlink transmissions. For example, rather than performing periodic SIB1 transmissions, the network entity might transmit a SIB1 based on a request from one or more UEs for the SIB1.

[0006] When operating in the energy saving modes described above, a UE may transition from an idle or inactive state to a connected state. In order to successfully make the transition to the connected state, the UE may transmit what may be referred to as an on-demand SIB1 request in order to obtain information used to make the transition. The UE can transmit the on-demand SIB1 request via a physical random access channel (PRACH) .

[0007] It is possible that multiple UEs may make requests for the SIB1 at or near the same time. It is also possible that different UEs may make requests for SIB1s based on different SSBs (such as SSBs associated with different cells, beams, or resource sets) , which can increase signaling overhead. Absent the techniques of this disclosure, the network entity may transmit multiple responses (e.g., random access responses (RARs) ) to the multiple requests and multiple on-demand SIB1s to the UEs. This can increase the overhead on the network entity for responding to on-demand SIB1 requests.

[0008] BRIEF SUMMARY

[0009] The systems, methods, and apparatuses of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0010] One innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a user equipment (UE) . The method includes receiving, from a first network entity or a second network entity, a random access channel (RACH) configuration for requesting a system information block type 1 (SIB1) in association with a synchronization signal block (SSB) configuration, the RACH configuration including at least one of one or more random access channel occasion (RO) selection parameters or one or more preamble selection parameters. The method further includes transmitting, to the first network entity, a first physical random access channel (PRACH) indicating a first SIB1 request for the SIB1 using at least one RO based on the one or more RO selection parameters or at least one preamble based on the one or more preamble selection parameters.

[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a first network entity. The method includes transmitting, to a UE, a RACH configuration for requesting a SIB1 in association with an SSB configuration, the RACH configuration including at least one of one or more RO selection parameters or one or more preamble selection parameters. The method further includes receiving, from the UE, a first PRACH indicating a first SIB1 request for a first SIB1. The  method further includes transmitting, to the UE, a response to the first PRACH. The method further includes transmitting, to the UE, the first SIB1.

[0012] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus. The apparatus includes a communication unit and a processing system configured to control the communication unit to implement any of the above-referenced methods. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0013] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Like reference numbers and designations in the various drawings indicate like elements. Note that the relative dimensions of the figures may not be drawn to scale. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0015] FIG. 1 shows an example wireless communication system and an implementation of a user equipment (UE) communicating a system information block type 1 (SIB1) request to obtain the SIB1 from a network entity.

[0016] FIG. 2A is a block diagram illustrating an example of receiving multiple requests for an on-demand SIB1.

[0017] FIG. 2B is a block diagram illustrating an example of on-demand SIB1 overhead associated with low beam quality.

[0018] FIG. 3 is a sequence diagram illustrating an example communication flow in which a UE can transmit a SIB1 request to obtain a SIB1 from a network entity.

[0019] FIG. 4 is a block diagram illustrating an example configuration for an on-demand SIB1 request.

[0020] FIG. 5 is a block diagram illustrating sharing random access channel occasions (ROs) between physical random access channels (PRACHs) for on-demand SIB1 requests and PRACHs for other types of functions.

[0021] FIG. 6 is a block diagram illustrating an example of power ramping based on reception status of a random access response (RAR) or on-demand SIB1.

[0022] FIG. 7 is a block diagram illustrating an example of RAR overhead reduction based on synchronization signal block (SSB) priority.

[0023] FIG. 8 is a block diagram illustrating a first example of RAR overhead reduction based on multiple on-demand SIB1 monitoring windows.

[0024] FIG. 9 is a block diagram illustrating a second example of RAR overhead reduction based on multiple on-demand SIB1 monitoring windows.

[0025] FIG. 10 is a block diagram illustrating an example of reducing SIB1 overhead via SIB1 negative acknowledgment (NACK) reporting.

[0026] FIG. 11 is a block diagram illustrating an example of reducing SIB1 overhead via RAR acknowledgement (ACK) reporting.

[0027] FIG. 12 is a block diagram illustrating an example of RO selection and / or preamble selection based on beam quality.

[0028] FIG. 13 is a flowchart illustrating first example operations of a UE according to aspects of this disclosure.

[0029] FIG. 14 is a flowchart illustrating first example operations of a network entity according to aspects of this disclosure.

[0030] FIG. 15 is a flowchart illustrating second example operations of a UE according to aspects of this disclosure.

[0031] FIG. 16 is a flowchart illustrating second example operations of a network entity according to aspects of this disclosure.

[0032] FIG. 17 shows a block diagram of an example UE and an example network entity.DETAILED DESCRIPTION

[0033] The following description is directed to certain implementations for the purpose of describing innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. Some of the examples in this disclosure are based on wireless communication according to the 3rd Generation Partnership Project (3GPP) wireless standards, such as the 4th generation (4G) Long Term Evolution (LTE) , 5th generation (5G) New Radio (NR) , and 6th generation (6G) standards. However, the described implementations can be implemented in any device, system, or network that is capable of transmitting and receiving radio frequency signals according to any  of the wireless communication standards, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 or 802.16 wireless standards, or other known signals that are used to communicate within a wireless, cellular, or internet of things (IoT) network, such as a system utilizing 4G, 5G, 6G, WiFi, or future radio technology.

[0034] In a wireless communication system, a network entity (such as a base station) and a user equipment (UE) can implement techniques to reduce power consumption. For example, a UE operates in a radio resource control (RRC) connected state when the UE has an active wireless connection with a network entity. During times when the UE does not have an active wireless connection with the network entity, the UE can enter a power saving mode. For example, the UE transitions from the RRC connected state to an RRC idle state or RRC inactive state. In the RRC idle state, the UE releases the RRC configuration. In the RRC inactive state, the UE suspends the RRC configuration and the RRC configuration can remain dormant until the UE transitions back to the RRC connected state. During the RRC idle or inactive states, the UE can obtain downlink synchronization signals and system information (SI) from the network entity, for example, via a system information type 1 block (SIB1) . The UE relies on SI from the network entity for various operations, such as cell selection (e.g., at power on) , cell-reselection, return from out of coverage, performing a random access procedure, and transitioning to RRC connected state, among other examples.

[0035] It is desirable to reduce signaling overhead and improve network energy performance. Some recent improvements to wireless communication technology are based on network energy saving (NES) in which the network entity eliminates or reduces some uplink and downlink transmissions. For example, the network entity might refrain from transmitting a SIB1 for some or all of the cells or beams operated by the network entity. Doing so can reduce signaling overhead and improve energy efficiency. However, a UE within a cell might rely on the SIB1 for various reasons. For example, a UE may need the SIB1 for random access procedure to initiate access, cell reselection, and / or beam selection. It is desirable for the network entity to refrain from transmitting SIB1, thereby reducing overhead and improving network efficiency. Meanwhile, it is desirable for the UE to obtain the SIB1 to enable connectivity to the wireless network. In such cases, the UE may transmit, to the network entity, a request for a SIB1.

[0036] When operating in the energy saving modes described above, a UE may transition from an idle or inactive state to a connected state. In order to successfully make the transition to the connected state, the UE may transmit what may be referred to as an on-demand SIB1 request in  order to obtain information used to make the transition. The UE can transmit the on-demand SIB1 request via a physical random access channel (PRACH) .

[0037] It is possible that multiple UEs may make requests for the SIB1 at or near the same time. It is also possible that different UEs may make requests for SIB1s based on different synchronization signal blocks (SSBs) (such as SSBs associated with different cells, beams, or resource sets) , which can increase signaling overhead. Absent the techniques of this disclosure, the network entity may transmit multiple responses (e.g., random access responses (RARs) ) to the multiple requests and multiple on-demand SIB1 s to the UEs. This can increase the overhead on the network entity for responding to on-demand SIB1 requests.

[0038] Various techniques of the disclosure relate to reducing the overhead of the network entity in responding to on-demand SIB1 requests. The network entity and the UE may use one or more of the techniques (singly or in combination) of this disclosure. In some implementations, the techniques increase the probability that the UEs use the same parameters when transmitting an on-demand SIB1 request. For example, the network entity may configure UEs with random access channel (RACH) occasion (RO) selection parameters that cause the UEs to use the same slot for transmitting on-demand SIB1 requests. Alternatively, or additionally, the network entity can configure UEs with preamble selection parameters that cause the UEs to use the same preamble for PRACH transmissions of on-demand SIB1 request. In some implementations, the network entity may configure the UEs to use the same random access-radio network temporary identifier (RA-RNTI) . The network entity may configure the UEs to use priorities associated with SSBs to increase the probability that the UEs associate the same SSB with the on-demand SIB1 request. In some aspects, the network entity can transmit one response and one SIB1 in response to the multiple on-demand SIB1 requests, thereby reducing the overhead when receiving multiple on-demand SIB1 requests.

[0039] FIG. 1 shows an example wireless communication system 100 and implementations of UE 102A and 102B communicating PRACHs 160A and 160B indicating a SIB1 request to receive a SIB1 from a network entity (e.g., first network entity 104A or second network entity 104B) Although illustrated as a smartphones in FIG. 1, the UE 102A and the UE 102B can be implemented as any suitable computing or electronic device, such as a mobile communication device, a modem, cellular phone, gaming device, navigation device, media device, laptop computer, desktop computer, tablet computer, smart appliance, vehicle-based communication system, an Internet-of-things (IoT) device (e.g., sensor node, controller / actuator node,  combination thereof) , and the like. The example wireless communication system 100 shows a first network entity 104A and a second network entity 104B. The first network entity 104A and the second network entity 104B may be the same network entity, such as a base station. In some implementations, the first network entity 104A and the second network entity 104B are collocated or implemented by common hardware of the example wireless communication system 100. In some implementations, the first network entity 104A and the second network entity 104B can be separate hardware, such as separate base stations. For brevity, this disclosure refers to a network entity 104, which can describe functions performed by either or both of the first network entity 104A or the second network entity 104B.

[0040] The network entity supports wireless communication with one or more UEs via radio frequency (RF) signaling using one or more applicable radio access technologies (RATs) as specified by one or more communications protocols or standards. The network entity may employ any of a variety of RATs, such as operating as a NodeB (or base transceiver station (BTS) ) for a Universal Mobile Telecommunications System (UMTS) RAT (also known as “3G” ) , operating as an enhanced NodeB ( “eNB” ) for a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) RAT, operating as a 5G node B ( “gNB” ) for a 3GPP Fifth Generation New Radio (5G NR) RAT, and the like. The network entity (e.g., base station, an Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B) , evolved Node B, eNodeB, eNB, Next Generation Node B, gNode B, gNB, ng-eNB, access point, radio head or the like) , may be implemented in a macrocell, microcell, small cell, picocell, or the like, or any combination thereof. In some aspects, the functionality, and thus the hardware components, of the network entity may be distributed across multiple network nodes or devices and may be distributed in a manner to perform the functions described herein. As one example, the functionality of the network entity may be distributed across a radio unit (RU) , distributed unit (DU) , or central unit (CU) .

[0041] The first network entity 104A, the second network entity 104B, the UE 102A, and the UE 102B communicate using wireless links. The wireless links can include one or more wireless links (e.g., radio links) or bearers implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3GPP LTE, 5G NR, and so forth. In some implementations, multiple wireless links are aggregated in a carrier aggregation to provide a higher data rate for the UE 102A. The network entities 104A and 104B may be part of a radio access network (RAN) , for example, an Evolved Universal Terrestrial  Radio Access Network, E-UTRAN, 5G NR RAN, or NR RAN. The network entities 104A and 104B may be connected to a core network (not shown) that provides access to services or other networks. The network entities 104A and 104B and the UEs 102A and 102B may be configured to use multiple-user multiple-input multiple-output (MU-MIMO) communication in which the network entity can transmit multiple downlink transmissions using beam forming and orthogonal frequency division multiplexing (OFDM) .

[0042] The network entity (e.g., network entity 104A or 104B) and a UE (e.g., UE 102A or UE 102B) utilize an uplink (UL) transmission path for RF transmissions (referred to as uplink transmissions) from the UE 102A to the network entity, and a downlink (DL) transmission path for RF transmissions (referred to as downlink transmissions) from the network entity to the UE. The UL transmission path may include a Physical Uplink Shared Channel (PUSCH) , a Physical Uplink Control Channel (PUCCH) , and a PRACH. The PUSCH is used for the transmission of user data, such as voice data, video data, or text message data from the UE to the network entity. Additionally, the PUSCH may be used to transmit control information (e.g., uplink control information (UCI) ) . The PUSCH may be shared by multiple UEs. The PUCCH is used for transmitting control information (e.g., UCI) from the UE to the network, such as channel quality feedback, scheduling requests, and acknowledgments. The PRACH is used for random access in the uplink direction, enabling the UE to access the system without a prior reservation. The DL transmission path may include one or more of a Physical Downlink Shared Channel (PDSCH) , a Physical Downlink Control Channel (PDCCH) , a Physical Broadcast Channel (PBCH) , or a paging channel. The PDSCH is used for transmission of user data from the network entity to the UE.The PDSCH may be shared by multiple UEs. As with the PUSCH, PDSCH data may be any type of information, such as voice data, video data, or text message data. The paging channel is used to notify the UE 102A that there is incoming traffic for it from the network entity.

[0043] RRC is a component of a radio interface protocol stack that the network entity and the UE use to communicate. Among other functions, the network entity and the UE use RRC messaging to establish and / or release radio connections and resources. In an RRC connected state, the UE has an active wireless radio connection with a network entity. When an active wireless radio connection is not needed, the UE can transition from the RRC connected state to an RRC idle or inactive state to release or suspend, respectively, the wireless radio connection.

[0044] The network entity transmits one or more SSBs. Among other features, an SSB includes downlink synchronization signals (such as the primary synchronization signal (PSS) and  secondary synchronization signal (SSS) ) so that the UE can maintain synchronization with the network entity. Each SSB also includes a master information block (MIB) and other information to enable the UE to obtain the SIB 1 via a PDSCH. While each cell has at least one SSB, the network entity can transmit multiple SSBs within a cell. For example, the network entity might transmit a different SSB for each of a plurality of beams or transmission reception points (TRPs) . Alternatively, or additionally, a network entity can operate multiple cells and transmit multiple SSBs for the cells. To conserve bandwidth and energy, the network entity might refrain from transmitting the SIB 1s for some or all of the SSBs that the network entity transmits.

[0045] In accordance with this disclosure, the network entity can provide, to a UE (e.g., UE 102A and / or UE 102B) , an on-demand SIB 1 request configuration 110 in association with an SSB configuration. The on-demand SIB 1 request configuration 110 enables the UE to transmit an on-demand SIB 1 request to a network entity (such as the first network entity 104A shown in FIG. 1) . In some implementations, the first network entity 104A can provide the on-demand SIB 1 request configuration 110. Alternatively, or additionally, a second network entity 104B can provide the on-demand SIB 1 request configuration 110 to the UE 102A. The on-demand SIB 1 request configuration 110 can include one or more RO selection parameters and / or one or more PRACH preamble selection parameters. The UE can receive one or more SSBs from the first network entity 104A. The UE determines to transmit a PRACH 160A indicating a SIB 1 request based on one or more triggering conditions being satisfied. As an example, a triggering condition might be satisfied when the UE is aware that the first network entity 104A is in an NES mode or when the UE does not receive the SIB 1 following the one or more SSBs.

[0046] In some aspects, the UE 102A selects an SSB 130A from among the one or more SSBs. The UE 102A selects an RO and preamble based on the RO selection criteria and / or the preamble selection criteria associated with the SSB 130A in the on-demand SIB 1 request configuration 110. The UE 102A transmits a PRACH 160A indicating a SIB 1 request based on the selected RO and selected preamble. The network entity (such as either the first network entity 104A or the second network entity 104B) can transmit the requested SIB 1 180A. Although FIG. 1 shows the UE 102A transmitting the PRACH 160A indicating a SIB 1 request to the first network entity 104A and receiving the SIB 1 180A from the first network entity 104A, other implementations are possible. For example, the UE 102A can transmit the PRACH 160A indicating the SIB 1 request to the second network entity 104B and receive the SIB 1 180A from either the first network entity 104A or the second network entity 104B. The UE 102B performs similar RO and  preamble selection with respect to SSB 130B to transmit PRACH 160B indicating a SIB 1 request to receive SIB 1 180B.

[0047] In response to receiving the PRACH 160A indicating the SIB 1 request, the network entity transmits a RAR to acknowledge receipt of the PRACH 160A. In addition, the network entity transmits the requested SIB 1 180A to the UE 102A.

[0048] As discussed above, the network entity 104A may incur increased overhead when multiple UEs request an on-demand SIB 1 at or near the same time. For example, UE 102A and UE 102B may both request an on-demand SIB 1 and the same time. The network entity 104A can configure the UE 102A and UE 102B with an on-demand SIB 1 request configuration 110 that facilitates implementation of the techniques of the disclosure described in detail below to reduce the overhead of the network entity 104A in responding to on-demand SIB 1 requests. In some implementations, the techniques increase the probability that the UE 102A and the UE 102B use the same parameters when transmitting PRACHs 160A and 160B that indicate the SIB 1 request. For example, the network entity 104A may configure UE 102A and UE 102B with RO selection parameters that cause the UE 102A and the UE 102B to use the same slot for transmitting on-demand SIB 1 requests. Alternatively, or additionally, the network entity can configure UEs with preamble selection parameters that cause the UE 102A and UE 102B to select the same preamble for PRACH 160A and PRACH 160B when transmitting an on-demand SIB 1 request. The network entity can then transmit a single response and a single SIB 1 to UEs 102A and 102B in response to the on-demand SIB 1 requests received from UE 102A and UE 102B. In other words, SIB 1 180A and SIB 1 180B are the same SIB 1. The transmission of a single RAR and a single SIB 1 enables the network entity to reduce the overhead when responding to the multiple on-demand SIB 1 requests.

[0049] In some implementations, the network entity may configure the UEs to use the same RA-RNTI. The network entity may configure the UEs to use priorities associated with SSBs to increase the probability that the UEs associate the same SSB with the on-demand SIB 1 request.

[0050] In some aspects, the network entity may configure the UEs to transmit an on-demand SIB 1 request based on one or more triggering conditions, or refrain from transmitting the on-demand SIB 1 request when certain conditions are met. For example, the network entity may configure the UEs to refrain from transmitting on-demand SIB 1 requests when beam quality is low, or if a SIB 1 has already been previously transmitted in response to another SIB 1 request.

[0051] In some aspects, the network entity may configure the UEs to repeat transmissions of on-demand SIB 1 requests to increase the probability that the network entity receives the SIB 1 request (s) , where the number of repetitions is based on beam quality. In some aspects, The UE may ramp up transmission power of an on-demand SIB 1 request in response to a failure to receive an RAR or SIB 1.

[0052] In some aspects, the network entity may configure the UEs to restrict transmission of on-demand SIB 1 requests during certain periods. For example, the network entity may configure the UEs to transmit SIB 1 requests during particular ROs within configured association periods.

[0053] One potential technical advantage associated with the techniques of the disclosure is that the overhead in processing on-demand SIB 1 requests may be reduced both on the network entity and the UE, thereby resulting in energy savings. Further, transmission slots may be freed for other purposes.

[0054] FIG. 2A is a block diagram illustrating an example of receiving multiple requests for an on-demand SIB 1. As discussed above, multiple UEs may request a SIB 1 (e.g., an on-demand SIB 1) at or near the same time. For example, the multiple UEs may receive SSBs (not shown) from the network entity. The UEs may select different SSBs (such as a first SSB, SSB1, and a second SSB, SSB2) . The different SSBs are associated with different PRACH configurations, e.g., different ROs. Each of the multiple UEs can use the PRACH transmission associated with the selected SSB for requesting a SIB 1 from the network entity. In this disclosure, references to an SSB in association with a PRACH transmission refers to the relationship in which a PRACH configuration corresponds with the SSB. For example, different SSBs may be associated with different ROs. Typically, a UE selects the SSB based on a signal quality metric of the SSB, such as synchronization signal reference signal received power (SS-RSRP) and a threshold that may be configured by the network entity. The UE then uses the RO associated with the SSB for the PRACH transmission. In some aspects, ifthe UE receives at least one SSB with a measured SS-RSRP above the configured threshold, the UE selects an SSB having the SS-RSRP above the configured threshold as the associated SSB. If the UE does not receive at least one SSB with a measured SS-RSRP above the configured threshold, the UE may select any SSB. Different UEs may select different associated SSBs for PRACH transmission, which may result in the network entity transmitting multiple RARs associated with the SSBs and multiple on-demand SIB 1 associated with the SSBs. Even ifthe UEs select the same SSB and use the same RO associated with the SSB for a PRACH indicating a request for a SIB 1, the PRACHs may have different RA- RNTIs and thus appear to the network entity as different requests for the SIB 1. Absent the techniques of this disclosure, the network entity may transmit multiple RARs because of the different RA-RNTIs corresponding to the PRACHs.

[0055] In the example shown in FIG. 2A, two UEs (e.g., UEs 102A and 102B of FIG. 1) may receive SSBs from a network entity (e.g., network entity 104A of FIG. 1) . At least one of the UEs may not be configured to implement the techniques of the disclosure. In this example, UE 102A may select a first SSB (SSB1) and UE 102B may select a second SSB (SSB2) . The UEs may send PRACH transmissions indicating a request for a SIB 1 to a network entity (e.g., network entity 104A of FIG. 1) . UE 102A transmits a PRACH 160A in slot 1 of example frame portion 200A and UE 102B transmits a PRACH 160B in slot 2. The network entity responds to the SIB 1 requests of the PRACH 160A and the PRACH 160B by transmitting a RAR 262A to UE 102A and transmitting a RAR 262B to UE 102B. The network entity transmits RAR 262A in slot 6 and RAR 262B in slot 7. Additionally, the network entity may transmit a SIB 1 180A to UE 102A and a SIB 1 180B to UE 102B. The network entity transmits the SIB 1 180A in slot 11 and the SIB 1 180B in slot 12.

[0056] As can be seen from the example of FIG. 2A, the network entity incurs overhead in transmitting multiple RARs and SIB 1 transmissions absent the techniques of the disclosure. For example, the RAR 262B and the SIB 1 180B may be duplicative of RAR 262A and SIB 1 180A. It may be the case that the UEs select the same SSB for their respective PRACHs. However, even in this case, the network entity may transmit multiple RARs because the PRACHs have different corresponding RA-RNTIs.

[0057] FIG. 2B is a block diagram illustrating an example of on-demand SIB 1 overhead associated with low beam quality. It may be the case that beams used for communication between the network entity and the UE are of low quality. For example, if the SS-RSRP, synchronization signal signal-to-noise and interference ratio (SS-SINR) , or synchronization signal reference signal received quality (SS-RSRQ) for the SSB is insufficient for adequate communications, the UE may fail to receive a RAR transmitted by the network entity during a RAR monitoring window in response to a PRACH requesting a SIB 1. Additionally, or alternatively, the UE may fail to receive a SIB 1 transmitted by the network entity in the on-demand SIB 1 monitoring window. Ifthe UE fails to receive a RAR or SIB 1, the UE may retransmit the PRACH to request the SIB 1. Similarly, ifthe SS-RSRP for the SSB is not of sufficient quality or the target received power for the PRACH is not configured properly (e.g., uplink interference is high) , the network  entity may fail to receive the PRACH from the UE. In this case, the UE may fail to receive a RAR in the RAR monitoring window, and the UE may retransmit the PRACH. These multiple PRACH retransmissions may cause higher overhead associated with requests for on-demand SIB 1s.

[0058] In the example shown in FIG. 2B, a UE (e.g., UE 102A of FIG. 1) transmits a PRACH 160A-1 to a network entity (e.g., network entity 104A of FIG. 1) to request an on-demand SIB 1 from the network entity. The UE transmits the PRACH 160A-1 in slot 1 of example frame portion 200B. In response to the PRACH 160A-l, the network entity may transmit, in slot 6, a RAR 262A to the UE. Further, the network entity may transmit, in slot 11, the requested on-demand SIB 1 180A. If there is a communications failure during the transmission of the PRACH, the RAR, and / or the SIB 1 such that the network entity does not receive the PRACH or the UE does not receive the RAR and / or the SIB 1, the UE may retransmit the PRACH (e.g., PRACH 160A-2) at slot 14. As can be seen in FIG. 2B, poor beam quality may lead to increased overhead incurred by the network entity in handling the retransmitted PRACH in slot 14.

[0059] FIGs. 3-16 describe various techniques for processing on-demand SIB 1 requests. In some examples that follow, the operations may be described as utilizing RRC signaling. Unless specified otherwise, RRC signaling may indicate a RRC reconfiguration message from the network entity to the UE 130, or a system information block (SIB) , where the SIB may be an existing SIB (e.g., SIB 1) or a new SIB (e.g., SIB J, where J is an integer above 21) transmitted by the network entity.

[0060] FIG. 3 is a sequence diagram illustrating an example communication flow 300 in which a UE can transmit a SIB 1 request to obtain a SIB 1 from a network entity. Although not illustrated for the sake of illustration clarity, various acknowledgements for messages illustrated in FIG. 3 may be implemented to ensure reliable operations for processing on-demand SIB 1 requests.

[0061] At operation 310, the UE 102A can receive an on-demand SIB 1 request configuration from the network entity 104A (or another network entity in the RAN such as network entity 104B) . In some aspects, the UE 102A may receive the on-demand SIB 1 request configuration while the UE 102A is in an RRC connected state 305. Although the UE 102A typically clears RRC configurations after leaving the RRC connected state 305, in accordance with aspects of this disclosure, the UE 102A may preserve the on-demand SIB 1 request configuration in memory for later use in the RRC idle or RRC inactive state 311. Although FIG. 3 shows the on-demand SIB 1 request configuration operation 310 occurring during the RRC connected state 305, other  implementations are possible. For example, the on-demand SIB 1 request configuration can be included in any downlink communication from the network entity 104A (or network entity 104B) , such as included in a PBCH or PDSCH. Alternatively, or additionally, the on-demand SIB 1 request configuration can be at least partially provided by the MIB, universal subscriber identity module (USIM) , or may be defined by a technical specification. In some other aspects, the UE 102A may receive the on-demand SIB 1 request configuration while the UE 102A is in an RRC idle or RRC inactive state 311.

[0062] FIG. 4 is a block diagram illustrating an example on-demand SIB 1 request configuration 410. In some aspects, the on-demand SIB 1 request configuration 410 may include a RACH configuration 431. The RACH configuration 431 may be associated with an SSB configuration. The on-demand SIB 1 request configuration 410 may optionally include a RAR configuration 433 and / or an on-demand SIB 1 configuration 435.

[0063] In some aspects, RACH configuration 431 may include RO (s) 432A, preambles 432B, RO selection parameters 432C, preamble selection parameters 432D, and power control parameters 432E. The RO (s) 432A indicates a set of one or more candidate ROs available for selection by the UE based on the RO selection parameters 432C. The preambles 432B indicate a set of one or more candidate preambles available for selection by the UE based on the preamble selection parameters 432D.

[0064] The RO selection parameters 432C include thresholds for SSB measurements such as SS-RSRP, SS-SINR, SS-RSRQ, channel quality indicator (CQI) , or pathloss. The UE 102A may select an RO from RO (s) 432A based on whether one or more of the RO selection parameters meet corresponding thresholds.

[0065] The preamble selection parameters 432D may be similar to, or the same as, RO selection parameters, and include thresholds for SSB measurements such as SS-RSRP, SS-SINR, SS-RSRQ, CQI, or pathloss. The UE 102A may select a PRACH preamble from candidate preambles 432B based on whether one or more of the preamble selection parameters meet corresponding thresholds.

[0066] The power control parameters 432E indicate power ramping step sizes that the UE 102A may use when the UE 102A retransmits a PRACH indicating a SIB 1 request. As described in further detail below, the UE 102A may increase transmission power based on the power control parameters 432E when retransmitting a PRACH to increase the probability that the network entity 104A receives the retransmitted PRACH in cases where the network entity does not respond to the initial PRACH indicating the SIB1 request.

[0067] Other power control parameters 432E may include a preamble target received power for PRACH transmissions including a SIB1 request, and a maximum number of preamble transmissions for PRACH transmissions including a SIB1 request.

[0068] In some aspects, RAR configuration 433 includes RAR search space 434A, RAR control resource set (CORESET) 434B, RA-RNTI 434C, uplink resources 434D, and downlink control information (DCI) size parameter (s) 434E. The RAR search space 434A is set of candidate resources within the PDCCH where the UE 102A expects to find a RAR transmitted by the first network entity 104A. The RAR CORESET 434B defines the CORESET that the UE 102A may use for receiving a RAR from network entity 104A. The RA-RNTI 434C indicates a pre-defined RA-RNTI or fields to be used to generate a simplified RA-RNTI. A description of the generation of a simplified RA-RNTI is provided below with respect to FIG. 7. The uplink resources 434D indicate one or more uplink resources that the UE 102A may use for transmitting acknowledgement information for a RAR. The DCI size parameter (s) 434E indicate one or more parameters that may be used to determine a DCI size or the frequency domain resource assignment (FDRA) indicated by the DCI for a PDCCH scheduling a PDSCH for a RAR and / or a PDCCH scheduling the PDSCH for an on-demand SIB1. Further details on these parameters and their use are provided below.

[0069] In some aspects, on-demand SIB1 configuration 435 includes uplink resource 436. The uplink resource 436 indicates one or more uplink resources that the UE 102A may use for transmitting acknowledgement information for a SIB1.

[0070] Returning to FIG. 3, at operation 330, the first network entity 104A may transmit one or more SSBs to the UE 102A. While in the RRC idle or RRC inactive state 311, the UE 102A can receive the one or more SSBs (such as the SSB 130A of FIG. 1) from the first network entity 104A. As shown in FIG. 3 (block 331) , the first network entity 104A might be in a NES mode and might not transmit the SIB1.

[0071] At operation 360, the UE 102A transmits a SIB1 request to the network entity 104A. In some aspects, the UE 102A transmits a PRACH indicating the SIB1 request. The UE 102A may transmit the SIB1 request based on one or more triggering conditions (e.g., criteria) being satisfied. Examples of such triggering conditions include one or more of the following:

[0072] ● The UE 102A is aware that the first network entity 104A is in a NES mode;

[0073] ● The UE 102A does not receive a SIB1 following receipt of an SSB at operation 330;

[0074] ● A beam quality, e.g., layer 1 reference signal received power (L1-RSRP) or the layer 1 signal-to-interference plus noise ratio (L1-SINR) , for the SSB associated with the SIB1 request is above a first threshold;

[0075] ● The cell is not barred, e.g., cellBarred is configured as notBarred;

[0076] ● The UE has not identified any other SSB that configures the PDCCH and / or PDSCH for SIB1 or that does not configure a SIB1 request;

[0077] ● The beam quality for other SSBs that configure the PDCCH and / or PDSCH for SIB1 or that does not configure a SIB1 request is below a second threshold;

[0078] ● A first timer to receive the SIB1 expires;

[0079] ● A second prohibit timer to transmit the SIB1 request expires;

[0080] ● A number of SIB1 request retransmissions (including or excluding the initial transmission) is below the maximum number of SIB1 request retransmissions; or

[0081] ● A third timer for cell reselection has not expired.

[0082] In some aspects, the UE 102A may check one or more of the above triggering conditions to determine whether or not to retransmit previous SIB1 request for which no response was received.

[0083] In some implementations, the first and / or second threshold may be predefined or pre-configured by the network entity. The first and / or second threshold may be based on L1-RSRP / L1-SINR.

[0084] At operation 362, the network entity 104A transmits a RAR to the UE 102A acknowledging receipt of the SIB1 request.

[0085] At operation 364, the UE 102A may optionally transmit an acknowledgement (ACK) or negative acknowledgement (NACK) in response to receiving the RAR at operation 362. Examples of cases where the UE may transmit an ACK or NACK at operation 364 are provided below with respect to FIG. 12.

[0086] At operation 380, the network entity 104A (or, in some cases, another network entity in the RAN) transmits the SIB1 180A in response to the SIB1 request of operation 360. For example, the first network entity 104A can transmit the SIB1 180A via a PDCCH and / or PDSCH that is indicated in the MIB of the SSB 130A associated with the request or predefined in the on-demand SIB1 request configuration 110 received at operation 310.

[0087] At operation 382, the UE 102A may optionally transmit an acknowledgement (ACK) or negative acknowledgement (NACK) in response to receiving the SIB1 at operation 380. Examples of cases where the UE may transmit an ACK or NACK at operation 382 are provided below with respect to FIG. 11.

[0088] FIG. 1 and FIG. 3 have provided some example implementations and concepts related to the processing of an on-demand SIB1 request to reduce overhead incurred by a network entity and / or a UE. The remaining figures include additional details and example implementations. Some of the examples in various figures can be combined with examples from another figure. When a figure refers to concepts previously described in another figure the descriptions of those related concepts are similarly related to the latter figure. Where possible, to reduce redundancy, the figures include like reference numbers to represent an event or message already described in a previous figure and the description of that event or message is omitted or summarized in the description of the latter figure.

[0089] FIG. 1, FIG. 3 and FIG. 4 have discussed a configuration for on-demand SIB1 requests and a communication process between a UE and a network entity where the UE can receive a SIB1 (i.e., and on-demand SIB1) from the network entity using SIB1 requests based on the configuration. In particular, the discussion of FIG. 3 includes the UE transmitting, via a PRACH, a request for a SIB1 using ROs and / or preambles selected based on the configuration. The network entity may transmit a RAR in response to the PRACH to acknowledge the request and may further transmit the SIB1 in response to the request. The discussion of FIG. 5 through FIG. 12 and other description below provides examples of techniques to reduce overhead of a network entity and UE associated with transmitting and processing on-demand SIB1 requests and responses to SIB1 requests. The techniques may be used singly or in various combinations. The description below includes a discussion of techniques for PRACH overhead reduction, RAR overhead reduction, and SIB1 overhead reduction.

[0090] Examples of techniques for PRACH overhead reduction will now be presented. A network entity (e.g., network entity 104A) and a UE (e.g., UE 102A) may use one or more of the techniques discussed below to reduce overhead associated with a UE′son-demand request for a SIB1 via a PRACH (e.g., a PRACH transmitted by the UE at operation 360 of FIG. 3) . The techniques may include sharing ROs between PRACHs used for on-demand SIB1 requests and PRACHs used for other purposes, avoiding PRACHs when beam quality is low, improving transmission coverage of PRACHs to avoid PRACH retransmission, performing power ramping  based on a reception status of an RAR and / or SIB1, and aggregating on-demand SIB1 requests into certain association periods.

[0091] FIG. 5 is a block diagram illustrating sharing ROs between PRACH for on-demand SIB1 requests and PRACHs for SIB1 associated with other types of functions. The network entity may configure ROs and preambles for PRACH transmissions. In some implementations, the network entity may configure a first subset of the ROs and a first subset of preambles for PRACHs used for on-demand SIB1 requests. The network entity may configure a second subset of the ROs and a second set of preambles for PRACHs to be used for purposes other than an on-demand SIB1 request.

[0092] In the example illustrated in FIG. 5, the network entity has configured the UE with N preambles 500, where each preamble has an associated preamble index 508. Preamble 502A and preamble 502B having preamble indexes of 11 and 12, respectively, have been configured for use in PRACH transmissions for requesting a SIB1. Preambles 506 having preamble indexes 1-10 and 13-N have been configured for use in PRACH transmissions for a purpose other than a SIB1 request. When the UE determines to transmit a PRACH including a SIB1 request, the UE may select the RO (s) and preamble based on the subset of ROs and preambles associated with the UE selected SSB that are configured for SIB1 requests.

[0093] The network entity may indicate the SSBs to be associated with ROs in the RACH configuration 431 (FIG. 4) . The UE may select the associated SSB based on all the configured transmitted SSBs. The UE may determine the RO (s) for the PRACH for SIB1 request based on the selected SSB. In some other aspects, the network entity may configure a subset of SSBs from the transmitted SSBs for the UE to use to determine the RO (s) for a PRACH indicating a SIB1 request.

[0094] In some aspects, the network entity may configure a first set of power control parameters and a second set of power control parameters in the PRACH configuration. The first set of power control parameters may be used for PRACH transmissions indicating a SIB1 request and the second set of power control parameters may be used for PRACH transmissions for a purpose other than SIB1 requests. In some aspects, the first set of power control parameters may include at least one of the following parameters:

[0095] ● Preamble target received power for PRACH transmissions including a SIB1 request;

[0096] ● Power ramping step size for PRACH transmissions including a SIB1 request;

[0097] ● Maximum number of preamble transmissions for PRACH transmissions including a SIB1 request.

[0098] In some aspects, the second set of power control parameters may include at least one of the following parameters:

[0099] ● Preamble target received power for PRACH transmissions for a purpose other than SIB1 requests;

[0100] ● Power ramping step size for PRACH transmissions for a purpose other than SIB1 requests; or

[0101] ● Maximum number of preamble transmissions for PRACH transmissions for a purpose other than SIB1 requests.

[0102] In some aspects, the second set of power control parameters may be used for both PRACH transmissions indicating a SIB1 request and for purposes other than SIB1 requests.

[0103] In some implementations, the network may configure the UE to avoid transmitting a PRACH indicating a SIB1 request when beam quality is low. For example, in some aspects, the UE may select an SSB for RO determination if the UE determines that the beam quality for a beam associated with the SSB has sufficient quality metrics. In some aspects, the UE selects an SSB based on one or more of the following measurements:

[0104] ● The SS-RSRP for the SSB is greater than a first threshold,

[0105] ● The SS-SINR for the SSB is greater than a second threshold,

[0106] ● The SS-RSRQ for the SSB is greater than a third threshold, or

[0107] ● The pathloss measured from the SSB is smaller than a fourth threshold

[0108] One or more of the thresholds used to determine if a beam is of sufficient quality may be predefined or configured by the network entity.

[0109] In the case that the UE cannot identify at least one valid SSB for RO selection for a cell (e.g., a beam meeting the threshold criteria above) , the UE may refrain from transmitting the PRACH indicating a SIB1 request to the network entity.

[0110] In some aspects, the network entity may configure the PRACH indicating a SIB1 request to be transmitted on a supplement uplink (SUL) carrier in addition to, or instead of, the standard UL carrier. In such aspects, the network entity may configure two sets of thresholds for determining beam quality, where the first set of thresholds may be applicable for RO selection for UL and the second set of thresholds may be applicable for RO selection for SUL. In some  aspects, the network entity may configure a common set of thresholds and criteria for RO selection for both the SUL and UL. In some other aspects, the network entity may configure the UE with separate thresholds and RO selection criteria for the SUL and UL. In one example, for RO selection for the SUL, the UE may select an RO based on the SS-RSRP and / or pathloss for the SUL and corresponding thresholds.

[0111] In some aspects, the SS-RSRP, SS-SINR, SS-RSRQ, or pathloss may be the SS-RSRP, SS-SINR, SS-RSRQ, or pathloss that the UE measured based on the SSB. In some aspects, the SS-RSRP, SS-SINR, SS-RSRQ, or pathloss may be a predicted value for the SS-RSRP, SS-SINR, SS-RSRQ, or pathloss.

[0112] In some implementations, the network entity may configure the UE to reduce the number of retransmissions of a PRACH indicating a SIB1 request. For example, in some aspects, the network entity may configure the UE to transmit N repetitions of a PRACH for SIB1 request. The network entity may configure the number of repetitions N of the PRACH. The probability that the network entity successfully receives the PRACH transmission may be increased via the multiple repetitions, thereby reducing the probability that the UE will need to retransmit the PRACH at a later time.

[0113] In some aspects, the network entity may configure a set of thresholds, e.g., rsrp-ThresholdMsg1-RepetitionNumX, for the UE to determine the number of repetitions for the PRACH transmission. The UE may determine the number of ROs based on the threshold for the PRACH repetitions. As an example, the network entity may configured the UE such that if rsrp-ThresholdMsg1-RepetitionNum8 is configured and the RSRP of the downlink pathloss reference is less than rsrp-ThresholdMsg1-RepetitionNum8, the UE may determine the number of ROs as 8; if rsrp-ThresholdMsg1-RepetitionNum4 is configured and the RSRP of the downlink pathloss reference is less than rsrp-ThresholdMsg1-RepetitionNum4, the UE may determine the number of ROs as 4; if rsrp-ThresholdMsg1-RepetitionNum2 is configured and the RSRP of the downlink pathloss reference is less than rsrp-ThresholdMsg1-RepetitionNum2, the UE may determine the number of ROs as 2. If none of the above thresholds are configured or met, the UE may determine the number of ROs based on the lowest PRACH repetition number configured by the network entity.

[0114] In some aspects, the UE may determine the N ROs for the PRACH repetitions based on the ROs associated with the selected SSB configured for the SIB1 request, where N is the number  of PRACH repetitions. The UE transmits PRACH repetitions on the N ROs. The N ROs may be consecutive in time and may use the same frequency resources.

[0115] FIG. 6 is a block diagram illustrating an example of power ramping based on reception status of a RAR or on-demand SIB1. In some implementations, the UE applies a power ramping step when the UE determines that a retransmission of the PRACH indicating the SIB1 request is to be performed. For example, the UE may determine that a retransmission of PRACH indicating a SIB1 request is to be performed for a PRACH associated with the same SSB as the initial transmission of PRACH indicating the SIB1 request. In this case, the UE may apply a first power ramping step if the UE receives a RAR but fails to receive a SIB1. The UE may apply a second power ramping step if the UE fails to receive RAR. In some aspects, the network entity may configure the UE with the first and second power ramping step. In some aspects, the UE may suspend the power ramping if it changes the spatial transmission filter for the PRACH indicating the SIB1 request.

[0116] In the example shown in FIG. 6, the UE transmits an initial PRACH 160A-1 indicating a request for a SIB1 at slot 1 of example frame portion 600 using a target receive (RX) power of X. At slot 6, the UE fails to receive a RAR 262A-1. The UE may fail to receive the RAR because the network entity failed to receive the initial PRACH 160A-1 or because the UE failed to receive and properly decode a RAR 262A-1 transmitted by the network entity in response to receiving the PRACH 160A-1. In this example, the UE retransmits the PRACH 160A-2 at slot 11 using a target RX power of X+step1, where step1 may be configured by the network entity.

[0117] In the example shown in FIG. 6, the UE successfully receives and decodes a RAR 262A-2 that is transmitted by the network entity in response to the retransmitted PRACH 160A-2. In this example, at slot 17, the UE fails to receive a SIB1 180A in response to the retransmitted PRACH indicating a SIB1 request. The UE may retransmit the PRACH 160A-3 at slot 20 using a second power ramping when it fails to receive the SIB1. In some aspects, the UE may set the target RX power to X+step1+step2, where step2 may be configured by the network entity. In some other aspects, the UE may set the target RX power to X+2*step2.

[0118] In one example, the UE may determine the target received power for a PRACH transmission occasion for PRACH retransmission in response to a failure to detect a RAR in response to a SIB1 request as:

[0119] where preambleReceivedTargetPower is the preamble_received_target_power value of the previous preamble transmission, DELTA_PREAMBLE is a power offset applied by the UE during transmission of the preamble, PREAMBLE_POWER_RAMPING_STEP1 indicates the first power ramping step, PREAMBLE_POWER_RAMPING_COUNTER indicates the current count of attempts to transmit the preamble, and POWER_OFFSET_2STEP_RA is a power offset used by the UE during a random access process. In some aspects, preambleReceivedTargetPower, DELTA_PREAMBLE, PREAMBLE_POWER_RAMPING_COUNTER, and POWER_OFFSET_2STEP_RA may be as defined in 3GPP TS 38.321.

[0120] In another example, the UE may determine the target received power for a PRACH transmission occasion for PRACH retransmission in response to a failure to detect a SIB1 in response to the SIB1 request as:

[0121] where PREAMBLE_POWER_RAMPING_STEP2 indicates the second power ramping step.

[0122] In some implementations, the network entity may configure UEs such that on-demand SIB1 requests from one or more UEs are aggregated into particular association periods. For example, in some aspects, the network entity may configure the UE with the periodicity X, where X is the periodicity of the ROs allocated for on-demand SIB 1 requests. For example, the network entity may configure the periodicity of the ROs using the SIB1-RequestPeriod. The network entity may configure the UE with one or more association period index numbers that may be smaller than the value of the periodicity. In such aspects, UEs requesting an on-demand SIB 1 transmit the PRACH indicating the SIB1 request on the ROs that are within the configured association period (s) for every X association periods.

[0123] Examples of techniques for RAR overhead reduction will now be presented. A network entity (e.g., network entity 104A) and a UE (e.g., UE 102A) may use one or more of the techniques discussed below to reduce overhead associated with a network entity's response to an on-demand request for a SIB1 via a RAR (e.g., a RAR transmitted by the network entity at operation 362 of FIG. 3) . The techniques may include selecting SSBs based on an SSB priority, generating a simplified RA-RNTI to reduce the number of RARs transmitted by the network entity, reducing the size of the RAR payload, checking a SIB1 broadcast status before transmitting a PRACH, and monitoring for RAR (and SIB1) during default or configured monitoring windows.

[0124] FIG. 7 is a block diagram illustrating an example of RAR overhead reduction based on SSB priority. In some implementations, when selecting an SSB associated with an RO for a PRACH, a UE may select an SSB from multiple candidate SSBs based on a priority corresponding to each of the multiple SSBs. As an example, if the UE identifies multiple candidate SSBs that are above a threshold, it may select the SSB from the multiple SSBs based on a priority order of the SSBs. In some aspects, the priority may be predefined. For example, the priority may be based on the index of the SSB, with a lower index indicating a higher priority. In some aspects, the network entity may configure a priority order for SSBs. Associating a priority with SSBs increases the probability that more than one UE will select the same SSB for RO selection and preamble selection which may result in the network entity receiving multiple SIB 1 requests for the same SIB 1. Because the network entity might only respond with a single RAR and SIB1 in response to the multiple SIB1 requests, the network entity's overhead in processing SIB 1 requests from multiple UEs may be reduced.

[0125] In the example shown in FIG. 7, a first UE (e.g., UE 102A of FIG. 1) may receive four candidate SSBs 702 from the network entity where the SSBs 702 have corresponding indexes 1, 2, 4, and 5. A second UE (e.g., UE 102B of FIG. 1) may receive four candidate SSBs 704 from the network entity where the SSBs 704 have corresponding indexes 1, 3, 5, and 8. For the purposes of this example, the UE determines an SSB priority based on the index of the SSB, with SSBs having a lower index have a higher priority than SSBs with a higher index.

[0126] The first UE and the second UE both receive SSBs with indexes 1 and 5 (among the other SSBs) . Because the SSB with the index of 1 (referred to as “SSB 1” ) has the highest priority, both the first UE and the second UE select the same SSB, SSB1, for determining the RO and preamble for a PRACH transmission indicating a request for a SIB1. As a result, the first UE  and the second UE transmit a PRACH 160A during the same RO (e.g., slot 1 of example frame portion 700) and having the same preamble. The network entity can respond with a single RAR 262A at slot 6 and a single SIB1 180A at slot 11.

[0127] For the purposes of this example, assume the second UE did not implement this technique. In this case, the second UE may select a different SSB (referred to as “SSB2” ) and may transmit a second PRACH at a different RO and / or having a different preamble than the first PRACH transmitted by the first UE. As a result, the network entity receives two different PRACHs requesting a SIB1 and responds with two RARs (RAR 262A at slot 6 and RAR 262B at slot 7) and two SIB1s (SIB1 180A at slot 11 and SIB1 180B at slot 12) . This increases the overhead experienced by the network entity when compared with the case in which the first UE and the second UE both select the same SSB, allowing the network entity to avoid transmitting RAR 262B and SIB1 180B.

[0128] In some implementations, the network entity may configure multiple UEs to use a common RA-RNTI for the purposes of transmitting an on-demand SIB1 request via a PRACH. The common RA-RNTI can be specific to on-demand SIB1 requests or can be configured for a group of UEs in the same cell / beam. In some implementations, the multiple UEs concurrently transmit on-demand SIB1 requests using a same PRACH (and RO) using the common RA-RNTI such that the network entity receives a single on-demand SIB 1 request that is a combination of multiple overlapping UE transmissions of SIB1 requests. A potential technical advantage of this approach is that overhead is reduced by the UEs concurrently transmitting the overlapping / same SIB1 requests and the network entity receives stronger combined uplink signaling of the S IB1 requests. In some implementations, the network entity can transmit a single RAR in response to the multiple overlapping on-demand SIB 1 requests. A potential technical advantage is that RAR signaling overhead is reduced.

[0129] In some implementations, the network entity may configure the UE to calculate a simplified RA-RNTI for PRACHs indicating a SIB1 request. The network entity and the UE traditionally calculate a Random Access Radio Network Temporary Identifier (RA-RNTI) according to the following formula: RA-RNTI=I+s_id+14×t_id+14×80×f_id+14×80×8×ul_carrier_id

[0130] where s_id is the index of the first OFDM symbol of the PRACH occasion (0 ≤ s_id ＜14) , t_id is the index of the first slot of the PRACH occasion in a system frame (0 ≤ t_id ＜ 80) ,  f_id is the index of the PRACH occasion in the frequency domain (0 ≤ f_id ＜ 8) , and ul_carrier_id is the UL carrier used for random access preamble transmission (0 for NUL carrier, and 1 for SUL carrier) .

[0131] The simplified RA-RNTI may use fewer parameters than those used in calculating the traditional RA-RNTI. The use of fewer parameters increases the probability that multiple UEs will calculate the same simplified RA-RNTI when requesting a SIB1. As is the case for a common RA-RNTI, the simplified RA-RNTI is effective in reducing network entity overhead when multiple UEs concurrently transmit on-demand SIB1 requests. The multiple UEs use transmit a same PRACH (and RO) where the PRACH includes the same simplified RA-RNTI such that the network entity receives a single on-demand SIB1 request that is a combination of multiple overlapping UE transmissions of SIB1 requests. In some aspects, the network entity may configure the RA-RNTI for the PDCCH and PDSCH for the RAR in response to PRACH indicating a SIB 1 request.

[0132] In some other aspects, the RA-RNTI for the PDCCH and PDSCH for the RAR in response to PRACH indicating a SIB1 request may be pre-defined. In some other aspects, the network entity and the UE may calculate the simplified RA-RNTI for the RAR in response to the PRACH indicating the SIB 1 request based on a subset of the information used for traditional RA-RNTI calculation. For example, the network entity and the UE may calculate a simplified RA-RNTI that includes various combinations of an index of the first symbol of the RO, an index of the first slot of the RO within a system frame, a frequency domain location of the RO, or uplink carrier for the PRACH. In some aspects, the network entity and the UE may exclude ul_carrier_id when calculating the simplified RA-RNTI. In one example, the network entity and the UE may calculate the simplified RA-RNTI based on one or more of the following: RA-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id RA-RNTI = 1 + s_id + 14 × t_id RA-RNTI = 1 + 14 × t_id + 14 × 80 × f_id RA-RNTI = 1 + 14 × 80 × f_id

[0133] In some implementations, the network entity may use various techniques to reduce the payload size of an RAR response. In some aspects, rather than transmitting a full medium access control (MAC) header for the RAR response to a SIB 1 request, the network entity may transmit a MAC sub-header only. In other words, the network entity may refrain from transmitting a MAC RAR.

[0134] In some aspects, the network entity may refrain from transmitting a Random Access Preamble Identifier (RAPID) in the MAC RAR sub-header. For example, the network entity may indicate the type field “T” of the MAC RAR sub-header as 0. In some other aspects, the network entity may configure the RAPID in the MAC RAR sub-header. In some examples, the UE may start to monitor for the SIB 1 in the on-demand SIB 1 monitoring window after it receives a RAR based on the RAPID that it used for the PRACH transmission indicating the SIB1 request. In some other examples, the UE may start to monitor for the on-demand SIB1 in the on-demand SIB1 monitoring window after it receives a RAR in response to a PRACH for SIB1 request regardless of whether the RAPID in the RAR is the same as the RAPID used for the PRACH transmission indicating the SIB 1 request. In such examples, the UE may ignore the indication of the RAPID in the RAR.

[0135] In some aspects, the network entity may transmit a PDCCH associated with the RA-RNTI, and refrain from transmitting the PDSCH for the RAR. In such aspects, after receiving the PDCCH associated with RA-RNTI, the UE may start to monitor for the on-demand SIB 1 in the on-demand SIB 1 monitoring window.

[0136] In some implementations, the network entity may configure the UE with at least one of the following:

[0137] ● A first indicator indicating whether the PDSCH for RAR in response to a PRACH indicating an-demand SIB 1 request is transmitted; of

[0138] ● A second indicator indicating whether the RAR in response to PRACH indicating a request for an on-demand SIB 1 is based on MAC sub-header only.

[0139] In some aspects, the network entity may configure the UE to indicate whether the UE can skip monitoring for, or detecting, a RAR. In such aspects, if the network entity configures the UE to skip monitoring for or detecting a RAR, the UE may start to monitor for the on-demand SIB1 after transmitting the PRACH indicating the SIB1 request. If the network entity does not configure the UE to skip monitoring for or detecting a RAR, the UE may start to monitor the on-demand SIB 1 after receiving an RAR for on-demand SIB 1.

[0140] In some implementations, the UE may determine a status of an on-demand SIB1 broadcast before requesting an on-demand SIB1. For example, the UE may determine the on-demand SIB 1 broadcast status by checking the ssb-SubcarrierOffset value in the MIB before UE transmits or retransmits the PRACH indicating a request for an on-demand SIB 1 transmission. With this additional check, the UE may be able to determine ifa SIB 1 has already been broadcast.  In the case that the check for the on-demand SIB1 status indicates that a SIB1 has already been broadcast, the UE may refrain from retransmitting the PRACH even if the previous PRACH transmission was unsuccessful or if UE fails to successfully receive a RAR in response to a previous PRACH transmission indicating a request for a SIB 1.

[0141] FIG. 8 is a block diagram illustrating a first example of RAR overhead reduction based on multiple on-demand SIB 1 monitoring windows. In some implementations, the network entity may configure the UE with one or more of a RAR monitoring window 808, a first on-demand monitoring window 812, and / or a second on-demand SIB1 monitoring window 810. The UE may monitor for an on-demand SIB1 during the RAR monitoring window 808 that starts after transmitting a PRACH 160A indicating a SIB1 request. In the example shown in FIG. 8, the UE transmits a PRACH 160A indicating a request for a SIB1 to the network entity in slot 1 of example frame portion 800. After sending the PRACH 160A, if the UE fails to receive a RAR 262A corresponding to the on-demand SIB1 request within the RAR monitoring window 808, the UE may start to monitor for the on-demand SIB1 in a first on-demand SIB1 monitoring window 812. The first on-demand SIB1 monitoring window 812 may be configured by the NE or pre-defined. The first on-demand SIB 1 monitoring window 812 may start after the end of the RAR monitoring window 808.

[0142] Ifthe UE receives the RAR 262A corresponding to the PRACH 160A, the UE may start to monitor for the on-demand SIB1 in a second on-demand SIB1 monitoring window 810. In some aspects, the second on-demand SIB1 monitoring window 810 may be configured by the network entity, for example, via RRC signaling. In some other aspects, the second on-demand SIB1 monitoring window 810 may be configured by, or indicated by, the RAR 262A. In some other aspects, the second on-demand SIB1 monitoring window 810 may be pre-defined. The second on-demand SIB 1 monitoring window 810 may start after Y symbols or slots after the last symbol of PDSCH and / or PDCCH for the RAR 262A, where Y may be pre-defined, configured or indicated by the network entity, or reported by the UE.

[0143] FIG. 9 is a block diagram illustrating a second example of RAR overhead reduction based on multiple on-demand SIB1 monitoring windows. In the example shown in FIG. 9, the RAR monitoring window 808 and the second on-demand SIB 1 monitoring window 810 may be as described above with respect to FIG. 8. In the example shown in FIG. 9, the UE may start to monitor for the on-demand SIB 1 during a third on-demand SIB 1 monitoring window 902 that begins Z symbols or slots after transmitting the PRACH 160A at the latest RO (transmitted at  slot 1 of example frame portion 900) indicating the request for a SIB1. The value of Z may be pre-defined, configured or indicated by the network entity, or reported by the UE. The third on-demand SIB 1 monitoring window 902 may be pre-defined or configured by the network entity. With regard to the UE complexity, the network entity may configure the UE with the same search space and CORESET for RAR and on-demand SIB1. In some aspects, ifthe UE fails to receive a RAR 262A within the RAR monitoring window 808, the UE may stop monitoring for the on-demand SIB 1. In some other aspects, if the UE fails to receive the RAR 262A within the RAR monitoring window 808, it may continue to monitor for the on-demand SIB1 in the third on-demand SIB 1 monitoring window 902 or stop monitoring for the on-demand SIB 1 in the third on-demand SIB1 monitoring window 902 and start to monitor for the on-demand SIB1 in the second on-demand SIB 1 monitoring window 810.

[0144] Examples of techniques for SIB 1 overhead reduction will now be presented. A network entity (e.g., network entity 104A) and a UE (e.g., UE 102A) may use one or more of the techniques discussed below to reduce overhead associated with a network entity's SIB1 transmission in response to an on-demand request for a SIB1 (e.g., a SIB1 transmitted by the network entity at operation 380 of FIG. 3) . The techniques may include avoiding unnecessary SIB1 transmissions using SIB1 ACK and / or NACK reporting, avoiding unnecessary SIB1 transmissions using RAR ACK and / or NACK reporting, improving the reliability of SIB1 transmission by transmitting multiple repetitions of the SIB 1, using early beam quality reporting to identify appropriate resource allocation for SIB 1 transmission, and indicating to the UEs that a SIB 1 will not be transmitted due to low beam quality.

[0145] FIG. 10 is a block diagram illustrating an example of reducing SIB 1 overhead via NACK reporting. In some implementations, the network entity may reduce overhead associated with retransmitting a SIB 1 based on a SIB 1 NACK report 1082 provided by the UEs requesting a SIB 1 (for example, at operation 382 of FIG. 3) . The network entity may use the SIB 1 NACK report 1082 to reduce unnecessary SIB1 retransmissions. In some aspects, the network entity may configure the UE with at least one transmission occasion for an uplink channel, e.g., PRACH, PUSCH, or PUCCH, for a UE that has sent a PRACH indicating a SIB 1 request. The PRACH, PUSCH, or PUCCH may be used by the UE to report whether the UE has received the requested SIB1 or not. In some aspects, the network entity may configure the at least one transmission occasion of an uplink channel in an on-demand SIB 1 monitoring window. The network entity may configure the time-domain location, frequency-domain location, and / or associated SSB for each transmission occasion of the uplink channel. The UE may transmit the uplink channel based on a RNTI that is pre-defined or configured by the NE via RRC signaling or RAR.

[0146] In the example shown in FIG. 10, one or more UEs transmit a PRACH 160A indicating a request for a SIB1 in slot 1 of example frame portion 1000. In slot 6, the network entity transmits a RAR 262A in response to receiving at least one PRACH 160A from at least one UE. In slot 11, the network entity transmits a SIB1 180A in response to receiving at least one PRACH 160A from at least one UE. In some aspects, the UE may transmit a NACK report 1082 via the uplink channel (e.g., the PRACH, PUSCH, or PUCCH) if the UE fails to receive on-demand SIB1 180A within an on-demand SIB1 monitoring window. In some aspects, the UE may refrain from transmitting the NACK report 1082 via the uplink channel if the UE receives the on-demand SIB1. The network entity may determine not to retransmit the SIB1 180A (e.g., at slot 91 in the example of FIG. 10) if it does not receive the NACK report 1082 via the uplink channel thereby indicating that all UEs that sent the PRACH 160A indicating a SIB1 request have successfully decoded the on-demand SIB1 180A transmitted at slot 11. In this case, overhead associated with retransmitting the SIB1 180A is reduced because it is likely an unnecessary SIB1 retransmission. The SIB1 retransmission may be unnecessary because if none of the UEs requesting the SIB1 were able to receive and decode the SIB1, it is likely that the UEs will also be unable to receive and decode a retransmitted SIB1.

[0147] In some other aspects, the UE may transmit an ACK report via the uplink channel if the UE receives the on-demand SIB1 180A, and may refrain from transmitting the ACK report via the uplink channel if it has failed to receive the on-demand SIB1 180A. In such aspects, the network entity may determine not to retransmit the SIB1 180A (e.g., at slot 91 in the example of FIG. 10) if it receives an ACK report via the uplink channel from each UE requesting the on-demand SIB1, thereby indicating that all UEs that sent the PRACH 160A indicating a SIB1 request have successfully decoded the on-demand SIB1 180A transmitted at slot 11.

[0148] FIG. 11 is a block diagram illustrating an example of reducing SIB1 overhead via ACK reporting. In some implementations, the network entity may reduce overhead associated with transmitting a SIB1 based on a RAR ACK report 1164 provided by the UEs requesting a SIB1 (for example, at operation 364 of FIG. 3) . The network entity may use the RAR ACK report 1164 to avoid unnecessary SIB1 transmissions. In some aspects, the network entity may configure the UE with at least one transmission occasion for an uplink channel, e.g., PRACH, PUSCH, or PUCCH, for a UE that has sent a PRACH indicating a SIB1 request. The PRACH, PUSCH, or  PUCCH may be used by the UE to report whether or not the UE has received a RAR in response the SIB1 request. In some aspects, the network entity may configure the at least one transmission occasion uplink channel in the RAR monitoring window or after the RAR monitoring window. The network entity may configure the time-domain location, frequency-domain location, and / or associated SSB for each transmission occasion of the uplink channel. The UE may transmit the uplink channel based on an RNTI that is pre-defined or configured by the NE via RRC signaling or RAR.

[0149] In the example shown in FIG. 11, one or more UEs transmit a PRACH 160A indicating a request for a SIB1 in slot 1 of 1100. In slot 6, the network entity transmits a RAR 262A in response to receiving at least one PRACH 160A from at least one UE. In some aspects, if a UE receives the RAR 262A, the UE may transmit a RAR ACK report 1164 via the uplink channel (e.g., the PRACH, PUSCH, or PUCCH) . The UE may refrain from transmitting the ACK report 1164 via the uplink channel if the UE fails to receive the RAR 262A during a RAR monitoring window. The network entity may determine not to transmit a SIB1 180A (e.g., at slot 14 in the example of FIG. 11) if the network entity does not receive an ACK report 1164 from at least one UE. This reduces the overhead in transmitting a potentially unnecessary SIB1 because if none of the UEs requesting an on-demand SIB1 were able to receive and decode the RAR 262A transmitted by the network entity in response to the SIB1 request, it is likely that the UEs will also be unable to receive and decode the SIB1 if it were to be transmitted by the network entity. In some aspects, the network entity may wait for retransmission of a PRACH indicating the SIB1 request before transmitting a SIB1.

[0150] In some other aspects, the UE may transmit a NACK report via the uplink channel if the UE fails to receive and decode the RAR 262A during the RAR monitoring window and may refrain from transmitting the NACK report via the uplink channel if the UE receives the RAR 262A. In such aspects, the network entity may determine not to transmit the SIB1 180A (e.g., at slot 14 in the example of FIG. 11) if it receives NACK report via the uplink channel from each UE requesting the on-demand SIB1, thereby indicating that all UEs that sent the PRACH 160A indicating a SIB1 request were unable to receive and decode the RAR 262A transmitted at slot 6.

[0151] In some implementations, the network entity may reduce overhead associated with SIB1 request processing by increasing the reliability of the SIB1 transmission to avoid repeated requests for the SIB1 from UEs that were unable to receive and decode the SIB1. In some aspects,  the network entity may configure a PDCCH or PDSCH for transmitting an on-demand SIB1 based on multiple repetitions of the transmission. In some aspects, the number of repetitions may be pre-defined. In some other aspects, the network entity may configure the number of repetitions via RRC signaling, a RAR or PDCCH scheduling the PDSCH. In some other aspects, the number of repetitions may be determined based on the PRACH for on-demand SIB1 request. For example, the network entity may configure the UE with multiple ROs or multiple preambles, where each RO or preamble may represent a different number of repetitions. In some aspects, the network entity may configure the UE with the multiple ROs and / or multiple preambles via the PDCCH or PDSCH for the SIB1.

[0152] In some aspects, the number of repetitions may be based on beam quality. For example, the network entity may configure the UE with multiple beam quality thresholds, e.g., ThresholdSib1-RepetitionNumX for X repetitions of SIB1 via the PDCCH or PDSCH. The UE may use the configured thresholds to determine the preamble or RO that corresponds to the number of requested repetitions for the PRACH transmission. In one example, if ThresholdSib1-RepetitionNumX is configured and the beam quality of the associated SSB is less than ThresholdSib1-RepetitionNumX, the UE may calculate the number of repetitions of SIB1 as X and select the corresponding preamble or RO for Xrepetitions. The UE may determine the beam quality by measuring SS-RSRP, SS-SINR, or SS-RSRQ.

[0153] FIG. 12 is a block diagram illustrating an example of RO and / or preamble selection based on beam quality. In some implementations, the network entity may configure different ROs and / or different preambles for a PRACH indicating a SIB1 request based on different beam quality ranges for the associated SSB. In some aspects, the beam quality may be SS-RSRP, SS-SINR, SS-RSRQ, or CQI. The different beam quality ranges may be orthogonal.

[0154] In the example shown in FIG. 12, the network entity has configured the UE with three categories of preambles 1200. A first preamble is configured for use when the beam quality is in a first range. A second preamble is configured for use when the beam quality is in a second range. One or more third preambles 1206 are configured for purposes other than SIB1 requests. Each preamble has an associated preamble index 508. The UE uses preamble 1202A (preamble index 11) for a PRACH indicating a SIB1 request when the UE calculates a beam quality for the SSB associated with the SIB1 request that is within the first range. The UE uses preamble 1202B (preamble index 12) when the UE calculates a beam quality for the SSB associated with the SIB1 request that is within the second range. The UE uses preambles 1206 having preamble  indexes 1-10 and 13-N for PRACH transmissions having a purpose other than a SIB1 request. After receiving the PRACH indicating the SIB request, the network entity may determine the target spectrum efficiency (SE) for the on-demand SIB1 transmission corresponding to the SIB1 request, and may allocate the time and / or frequency domain resources for the PDCCH and / or PDSCH according to the target SE.

[0155] In some implementations, the network entity may reduce overhead associated with processing on-demand SIB1 requests by indicating that an on-demand SIB1 will not be transmitted due to low beam quality. In some aspects, after receiving the PRACH indicating a SIB1 request, the network entity may transmit a RAR which indicates whether or not the UE should start to monitor for the on-demand SIB1. In some examples, the network entity may determine the beam quality for the UE is low and to not transmit the on-demand SIB1. In this case, the network entity may indicate to the UE that the on-demand SIB1 will not be transmitted in the RAR acknowledging the PRACH.

[0156] In some aspects, after receiving the RAR indicating that the UE will not transmit an on-demand SIB1 in response to the SIB1 request, the UE may refrain from retransmission of the PRACH indicating the SIB1 request. Alternatively, or additionally, the UE may transmit a PRACH for SIB1 request after a prohibit timer for a SIB1 request expires. The UE may start or restart the prohibit timer when transmitting a PRACH indicating the SIB1 request, and stop the prohibit timer after it receives the on-demand SIB1 from the network entity. The duration of the prohibit timer may be pre-defined or configured by the network entity.

[0157] The network entity may indicate that the UE will receive the on-demand SIB1 from another cell.. The network entity may indicate the other cell via a RAR transmitted in response to the request for the on-demand SIB1. For example, the network entity may configure a list of candidate cells for on-demand SIB1 transmission in the on-demand SIB1 configuration (e.g., the on-demand SIB1 configuration transmitted at operation 310 of FIG. 3) , and may indicate one of the candidate cells for that the UE is to monitor for the on-demand SIB1 in the RAR.

[0158] In some implementations, the network entity and the UE may determine the DCI size or the FDRA indicated by the DCI for a PDCCH scheduling a PDSCH for the RAR and / or a PDCCH scheduling the PDSCH for an on-demand SIB1.

[0159] In cases where a PDCCH schedules a PDSCH for the on-demand SIB1, in some aspects, the DCI size or FDRA may be based on a bandwidth configured for CORESET #0, e.g., controlResourceSetZero, or a reference CORESET, where the CORESET #0 or the reference  CORESET may be pre-defined, configured by the SSB, configured by the control signaling for on-demand SIB1 configuration, or configured by the RAR. In some other aspects, the DCI size or FDRA may be based on the bandwidth configured for a downlink bandwidth part (e.g., initial downlink bandwidth part, e.g., initialDownlinkBWP) , where the downlink bandwidth part may be pre-defined, configured by the control signaling for on-demand SIB1 configuration, or configured by the RAR. In some other aspects, the DCI size or FDRA may be based on a bandwidth configured by the on-demand SIB1 configuration or the RAR.

[0160] In some aspects, the DCI size or FDRA may be based on a bandwidth of the SSB associated with the SIB1 request.

[0161] In some aspects, the DCI size or FDRA may be based on a pre-defined bandwidth that is in turn based on the location of the SSB and / or the carrier frequency for the cell.

[0162] In an example implementation, the network entity may indicate the FDRA for the scheduled PDSCH using bits, where NRB indicates one of the bandwidths described above used for determining the DCI size and FDRA. In some aspects, the indication of the DCI field may be based on 3GPP TS 38.212 section 7.3.1.2.1. The network entity may transmit the PDCCH and PDSCH for RAR and on-demand SIB1 based on one of the bandwidths described above. The network entity may transmit the PDCCH and PDSCH for a RAR and on-demand SIB1 based on a common bandwidth or separate bandwidths.

[0163] In some implementations, the network entity may configure the CORESET #0 or the reference CORESET for the cell via the on-demand SIB1 configuration of operation 310 of FIG. 3. The UE may refrain from transmitting a PRACH indicating a SIB1 request for the cell the UE does not receive the configuration of CORESET #0 or the reference CORESET with the on-demand SIB1 configuration.

[0164] In some implementations, the network entity may configure at least one of the CORESET #0 or reference CORESET #0 or (initial) downlink bandwidth part for the cell with the on-demand SIB1 configuration of operation 310 of FIG. 3. The UE may refrain from transmitting a PRACH indicating a SIB1 request for the cell if the UE does not receive the configuration of the CORESET #0 or reference CORESET #0 or (initial) downlink bandwidth part with the on-demand SIB1 configuration.

[0165] FIG. 13 through FIG. 16 show example operations according to aspects of this disclosure. Although the illustrated flow charts depict a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example,  some of the operations depicted may be performed in parallel or in a different sequence that does not materially affect the function of the routine. In other examples, different components of an example device or system that implements the routine may perform functions at substantially the same time or in a specific sequence.

[0166] FIG. 13 is a flowchart illustrating first example operations 1300 of a UE according to aspects of this disclosure. The operations of FIG. 13 can be performed by any UE, including any of the UEs described in this document such as UE 102A or 102B of FIG. 1 and FIG. 3, and UE 1702 of FIG. 17.

[0167] At block 1310, and as described above with respect to FIG. 3, operation 310, the UE receives an on-demand SIB1 request configuration 410 (FIG. 4) from a network entity. In some aspects, the UE may receive the on-demand SIB1 request configuration while the UE is in an RRC connected state.

[0168] At block 1330, and as described above with respect to FIG. 3, operation 330, the UE receives one or more SSBs from the network entity. For example, while in an RRC idle or RRC inactive state, the UE may receive the one or more SSBs (such as the SSB 130A of FIG. 1) from the network entity. The network entity might be in an NES mode and might not automatically transmit a SIB1.

[0169] At block 1360, and as described above with respect to FIG. 3, operation 360, the UE transmits a SIB1 request to the network entity. In some aspects, the UE transmits a PRACH indicating the SIB1 request.

[0170] At block 1362, and as described above with respect to FIG. 3, operation 362, the UE receives a RAR from the network entity acknowledging receipt of the SIB1 request.

[0171] At block 1364, and as described above with respect to FIG. 3, operation 364, the UE optionally transmits an acknowledgement or negative acknowledgement in response to receiving the RAR at block 1362. Examples of cases where the UE may transmit an ACK or NACK have been discussed above with respect to FIG. 11.

[0172] At block 1380, and as described above with respect to FIG. 3, operation 380, the UE receives SIB1 in response to the SIB1 request of block 1360. For example, the UE may receive the SIB1 via a PDCCH / PDSCH that is indicated in a MIB of the SSB associated with the request or predefined in the on-demand SIB1 request configuration received at block 1310.

[0173] At block 1382, and as described above with respect to FIG. 3, operation 382, the UE optionally transmits an ACK or NACK in response to receiving the SIB1 at block 1380. Examples of cases where the UE may transmit an ACK or NACK are discussed above with respect to FIG. 10.

[0174] FIG. 14 is a flowchart illustrating first example operations 1400 of a network entity according to aspects of this disclosure. The operations of FIG. 14 can be performed by any network entity, including the network entities described in this document such as network entities 104A and 104B of FIG. 1 and FIG. 3, and the network entity 1704 of FIG. 17.

[0175] At block 1410 and as described above with respect to FIG. 3, operation 310, the network entity optionally transmits an on-demand SIB1 request configuration (e.g., on-demand SIB1 request configuration 410 of FIG. 4) to a UE. In some aspects, the network entity can transmit the on-demand SIB1 request configuration while the UE is in an RRC connected state 305.

[0176] At block 1430 and as described above with respect to FIG. 3, operation 330, the network entity transmits one or more SSBs to the UE. For example, while the UE is in an RRC idle or RRC inactive state, the network entity may transmit the one or more SSBs (such as the SSB 130A of FIG. 1) to the UE.

[0177] At block 1460 and as described above with respect to FIG. 3, operation 360, the network entity receives a SIB1 request from the UE. In some aspects, the network entity receives a PRACH indicating the SIB1 request from the UE.

[0178] At block 1462, and as described above with respect to FIG. 3, operation 362, the network entity transmits a RAR to the UE acknowledging receipt of the SIB1 request from the UE.

[0179] At block 1464, and as described above with respect to FIG. 3, operation 364, the network entity optionally receives an ACK or NACK in response to transmitting the RAR at block 1362. Examples of cases where the network may receive an ACK or NACK from the UE have been discussed above with respect to FIG. 11.

[0180] At block 1480, and as described above with respect to FIG. 3, operation 380, the network entity transmits SIB1 in response to the SIB1 request received at block 1460. For example, the network entity may transmit the SIB1 via a PDCCH / PDSCH that is indicated in a MIB of the SSB associated with the request or predefined in the on-demand SIB1 request configuration transmitted at block 1410.

[0181] At block 1482, and as described above with respect to FIG. 3, operation 382, the network entity optionally receives an ACK or NACK in response to transmitting the SIB1 at block 1480. Examples of cases where the UE may transmit an ACK or NACK are discussed above with respect to FIG. 10.

[0182] FIG. 15 is a flowchart illustrating second example operations 1500 of a UE according to aspects of this disclosure. The operations of FIG. 15 can be performed by any UE, including any of the UEs described in this document such as UE 102A or 102B of FIG. 1 and FIG. 3, and UE 1702 of FIG. 17.

[0183] At block 1510, and as described above with respect to FIG. 3, operation 310, and FIG. 13, block 1310, the UE can a random access channel (RACH) configuration for requesting a system information block type 1 (SIB1) in association with a synchronization signal block (SSB) configuration, the RACH configuration including at least one of one or more random access channel occasion (RO) selection parameters or one or more preamble selection parameters.

[0184] At block 1560 and as described above with respect to FIG. 3, operation 360 and FIG. 13, block 1360, the UE transmits, to a network entity, a first physical random access channel (PRACH) indicating a first SIB1 request for the SIB1 using at least one RO based on the one or more RO selection parameters or at least one preamble based on the one or more preamble selection parameters.

[0185] FIG. 16 is a flowchart illustrating second example operations 1600 of a network entity according to aspects of this disclosure. The operations of FIG. 16 can be performed by any network entity, including the network entities described in this document such as network entities 104A and 104B of FIG. 1 and FIG. 3, and the network entity 1704 of FIG. 17.

[0186] In block 1610, and as described above with respect to FIG. 3, operation 310 and FIG. 14, block 1410, the network entity transmits, to a user equipment (UE) , a random access channel (RACH) configuration for requesting a system information block type 1 (SIB1) in association with a synchronization signal block (SSB) configuration, the RACH configuration including at least one of one or more random access channel occasion (RO) selection parameters or one or more preamble selection parameters.

[0187] In block 1660, and as described above with respect to FIG. 3, operation 360 and FIG. 14, block 1460, the network entity receives, from the UE, a first PRACH indicating a first SIB1 request for a first SIB1.

[0188] In block 1662, and as described above with respect to FIG. 3, operation 362 and FIG. 14, block 1462, the network entity transmits, to the UE, a response to the first PRACH.

[0189] In block 1680, and as described above with respect to FIG. 3, operation 380 and FIG. 14, block 1480, the network entity transmits, to the UE, the first SIB1.

[0190] FIG. 17 is a block diagram illustrating an example UE 1702 and an example network entity 1704. Note that the depicted hardware configurations represent the processing components and communication components of a network entity 1704 (such as the first network entity 104A or the second network entity 104B described herein) and a UE 1702 (such as the UE 102A and UE 102B described herein) . The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like.

[0191] The UE 1702 includes antennas 1703A, a radio frequency front end (RF front end) 1703B, and radio-frequency transceivers (e.g., an LTE transceiver 1703D and a 5G NR transceiver 1703C) for communicating with the network entity 1704. The RF front end 1703B includes one or more modems configured for the corresponding RAT (s) employed (for example, 3GPP Fifth Generation New Radio 5G NR) , one or more analog-to-digital converters (ADCs) , one or more digital-to-analog converters (DACs) , signal processors, and the like. In the example illustrated in FIG. 17, the RF front end 1703B of the UE 1702 may couple or connect the 5G NR transceiver 1703C to the antennas 1703A to facilitate various types of wireless communication. The RF front end 1703B operates, in effect, as a physical (PHY) transceiver interface to conduct and process signaling between the one or more processor (s) 1703E and antennas 1703A so as to facilitate various types of wireless communication.

[0192] The antennas 1703A of the UE 1702 include an array of multiple antennas that may be tuned to one or more frequency bands associated with a corresponding RAT. The antennas 1703A and the RF front end 1703B are tuned to, and / or be tunable to, one or more frequency bands defined by the 3GPP 5G NR communication standards and implemented by the 5G NR transceiver 1703C. Additionally, the antennas 1703A, the RF front end 1703B, and / or the 5G NR transceiver 1703C can be configured to support beamforming for the transmission and reception of communications with the network entity 1704. By way of example and not limitation, the antennas 1703A and the RF front end 1703B may be implemented for operation in sub-gigahertz bands, sub-6 GHz bands, and / or above 6 GHz bands that are defined by the 3GPP LTE and 5G NR communication standards.

[0193] The UE 1702 also includes processor (s) 1703E and computer-readable storage media (CRM) 1703F. The processor (s) 1703E may include, for example, one or more central processing units, graphics processing units (GPUs) , or other application-specific integrated circuits (ASIC) , and the like. To illustrate, the processor (s) 1703E may include an application processor (AP) utilized by the UE 1410 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor of the RF front end 1703B. The CRM 1703F may include any suitable memory or storage device such as random-access memory (RAM) , static RAM (SRAM) , dynamic RAM (DRAM) , non-volatile RAM (NVRAM) , read-only memory (ROM) , Flash memory, solid-state drive (SSD) or other mass-storage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processor (s) 1703E and other components of the UE 1702 to perform the various functions described herein and attributed to the UE 1702. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown) , and various software applications (not shown) , which are executable by processor (s) 1703E to enable user-plane communication, control-plane signaling, and user interaction with the UE 1702.

[0194] The processor (s) 1703E along with other processors of the UE 1702 that are used to implement the techniques described herein may be individually or collectively referred to as “a processing system. ” One or more of RF front end 1703B, LTE transceiver 1703D, 5G NR and LTE transceiver 1703D may be individually or collectively referred to as a “communication unit. ”

[0195] Turning to the hardware of the network entity 1704, it is noted that although FIG. 17 illustrates an implementation of the network entity 1704 as a single network node (for example, a 5G NR Node B, or “gNB” ) , the functionality, and thus the hardware components, of the network entity 1704 instead may be distributed across multiple network nodes or devices and may be distributed in a manner to perform the functions described herein. As one example, the functionality of network entity 1704 may be distributed across a radio unit (RU) , distributed unit (DU) , or central unit (CU) .

[0196] The network entity 1704 includes antennas 1705A, a radio frequency front end (RF front end) 1705B, and one or more 5G NR transceivers 1705C for communicating with the UE 1702. The RF front end 1705B of the network entity 1704 may couple or connect the 5G NR transceivers 1705C to the antennas 1705A to facilitate various types of wireless  communication. Similar to RF front end 1703B, the RF front end 1705B includes one or more modems, one or more ADCs, one or more DACs, and the like. RF front end 1705B receives the one or more RF signals, for example, RF signals from UE 1702, and pre-processes the one or more RF signals to generate data from the RF signals that is provided as input to processes and / or applications executing on network entity 1704. This pre-processing may include, for example, power amplification, conversion of band-pass signaling to baseband signaling, initial analog-to-digital conversion, and the like.

[0197] The antennas 1705A of the network entity 1704 may be configured individually and / or as one or more arrays of multiple antennas. The antennas 1705A and the RF front end 1705B may be tuned to, and / or be tunable to, one or more frequency band defined by the 3GPP 5G NR communication standards, and implemented by the 5G NR transceivers 1705C. Additionally, the antennas 1705A, the RF front end 1705B, and the 5G NR transceiver (s) 1705C may be configured to support beamforming, such as Massive-MIMO, for the transmission and reception of communications with the UE 1702.

[0198] The network entity 1704 also includes processor (s) 1705D and computer-readable storage media (CRM) 1705E. The processor (s) 1705D may include, for example, one or more central processing units, graphics processing units (GPUs) , or other application-specific integrated circuits (ASIC) , and the like that may be used to perform the various functions described herein and attributed to the network entity 1704 and for other functions. To illustrate, the processor (s) 1705D may include an application processor (AP) utilized by the network entity 1704 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor of the RF front end 1705B to enable communication with the UE 1702. In at least some aspects, the processor (s) 1705D configures the 5G NR transceiver (s) 1705C for communication with the UE 1702, TRPs, and radio units via fronthaul interface 1707A, as well as communication with a core network. In some aspects, the network entity 1704 includes an inter-network entity interface 1707B, such as an Xn and / or X2 interface, which the processor (s) 1705D configures to exchange user-plane and control-plane data with another network entity, to manage the communication of the network entity 1704 with the UE 1702. The network entity 1704 includes a core network interface 1707C that the processor (s) 1705D configures to exchange user-plane and control-plane data with core network functions and entities.

[0199] The processor (s) 1705D along with other processors of the network entity 1704 that are used to implement the techniques described herein may be individually or collectively referred to as “a processing system. ” One or more of RF front end 1705B, 5G NR transceiver (s) 1705C, fronthaul interface 1707A, inter-network entity interface 1707B, and core network interface 1707C may be individually or collectively referred to as a “communication unit. ”

[0200] FIG. 1 through FIG. 17 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims, some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations differently. Alternatively, or in addition to the other examples described herein, examples include any combination of the following implementation options (enumerated as clauses for reference) .

[0201] Clause 1. A method for wireless communication by a user equipment (UE) , the method comprising: receiving, from a first network entity or a second network entity, a random access channel (RACH) configuration for requesting a system information block type 1 (SIB1) in association with a synchronization signal block (SSB) configuration, the RACH configuration including at least one of one or more random access channel occasion (RO) selection parameters or one or more preamble selection parameters; and transmitting, to the first network entity, a first physical random access channel (PRACH) indicating a first SIB1 request for the SIB1 using at least one RO based on the one or more RO selection parameters or at least one preamble based on the one or more preamble selection parameters.

[0202] Clause 2. The method of clause 1, further comprising selecting at least one RO based on the one or more RO selection parameters or at least one preamble based on the one or more preamble selection parameters.

[0203] Clause 3. The method of clause 2, further comprising at least one of: monitoring, during a first monitoring window after the transmitting the first SIB1 request, for a random access response (RAR) to the first PRACH; monitoring for the SIB1 during a second monitoring window based on a reception of the RAR in the first monitoring window; or monitoring for the SIB1 during a third monitoring window different from the second monitoring window based on a failure to receive the RAR in the first monitoring window.

[0204] Clause 4. The method of clause 3, further comprising monitoring for the SIB1 during a fourth monitoring window that starts after the first PRACH and ends on or before a start of the second monitoring window.

[0205] Clause 5. The method of clauses 3 or 4, further comprising at least one of: transmitting a first acknowledgement (ACK) to the RAR; transmitting a first negative acknowledgment (NACK) to the RAR; transmitting a second ACK to the SIB1; or transmitting a second NACK to the SIB1.

[0206] Clause 6. The method of clauses 3 or 4, further comprising at least one of: refraining from retransmitting the first PRACH when the RAR includes an indication that the first network entity will refrain from transmitting the SIB1; or refraining from transmitting a second PRACH indicating a second SIB1 request based on a SIB1 broadcast status.

[0207] Clause 7. The method of any one of clauses 1-6, wherein at least one of: the at least one RO is included in a first subset of a plurality of ROs configured for on-demand SIB1 request and a second subset of the plurality of ROs is configured for a purpose other than an on-demand SIB1 request; or the at least one preamble is included in a first subset of a plurality of preambles configured for the on-demand SIB1 request and a second subset of the plurality of preambles is configured for the purpose other than the on-demand SIB1 request.

[0208] Clause 8. The method of any one of clauses 1-7, further comprising: transmitting the first PRACH based on a first configuration of power control parameters; and transmitting at least one other PRACH based on a second configuration of power control parameters different from the first configuration of power control parameters, the second configuration for a PRACH transmission other than an on-demand SIB1 request.

[0209] Clause 9. The method of any one of clauses 1-8, further comprising: transmitting the first PRACH based on a first power level indicated in a power control configuration; and retransmitting the first PRACH based on a power ramping step indicated in the power control configuration.

[0210] Clause 10. The method of any one of clauses 1-9, further comprising receiving an SSB based on the SSB configuration, wherein the transmitting the first PRACH is based on one or more triggering conditions being satisfied, and wherein the one or more triggering conditions include at least one of: a synchronization signal reference signal received power (SS-RSRP) for the SSB is greater than a first threshold; a synchronization signal signal-to-noise and interference ratio (SS-SINR) for the SSB is greater than a second threshold; a synchronization signal reference  signal received quality (SS-RSRQ) for the SSB is greater than a third threshold; or a pathloss measured based on the SSB is smaller than a fourth threshold.

[0211] Clause 11. The method of clause 10, further comprising refraining from transmitting a second PRACH indicating a second SIB1 request when none of the one or more triggering conditions are met.

[0212] Clause 12. The method of any one of clauses 1-11, wherein the transmitting the first PRACH includes transmitting repetitions of the first PRACH based on a configured number of repetitions and a downlink quality threshold.

[0213] Clause 13. The method of any one of clauses 1-12, further comprising receiving, from the first network entity, a configuration of one or more association periods, the association periods based on a periodicity of ROs, wherein the transmitting the first PRACH includes transmitting the first PRACH within one of the one or more association periods.

[0214] Clause 14. The method of any one of clauses 1-13, further comprising receiving a plurality of SSBs, and wherein the transmitting the first PRACH includes transmitting the first PRACH based on an SSB of the plurality of SSBs having a highest priority.

[0215] Clause 15. The method of any one of clauses 1-14, wherein the preamble selection parameters include beam quality range parameters, the method further comprising: determining a beam quality; and selecting a preamble based on the beam quality and the beam quality range parameters, wherein the transmitting the first PRACH uses the selected preamble.

[0216] Clause 16. A method for wireless communication by a network entity, the method comprising: transmitting, to a user equipment (UE) , a random access channel (RACH) configuration for requesting a system information block type 1 (SIB1) in association with a synchronization signal block (SSB) configuration, the RACH configuration including at least one of one or more random access channel occasion (RO) selection parameters or one or more preamble selection parameters; receiving, from the UE, a first physical random access channel (PRACH) indicating a first SIB1 request for a first SIB1; transmitting, to the UE, a response to the first PRACH; and transmitting, to the UE, the first SIB1.

[0217] Clause 17. The method of clause 16, wherein the transmitting the response to the first PRACH includes transmitting at least one of: a random access response (RAR) that omits a medium access control (MAC) header and includes a first MAC sub-header; a second MAC sub-header that omits a random access preamble identifier (RAPID) ; or the second MAC sub-header with a type field indicating the second MAC sub-header omits the RAPID.

[0218] Clause 18. The method of clauses 16 or 17, further comprising generating a random access radio network temporary identifier (RA-RNTI) that is not based on a carrier identifier, wherein the RA-RNTI is included in the response to the first PRACH.

[0219] Clause 19. The method of any one of clauses 16-18, further comprising: refraining from retransmitting the first SIB1 in response to determining that each of a plurality of UEs requesting the first SIB1 received the first SIB1.

[0220] Clause 20. The method of any one of clauses 16-19, further comprising: receiving, from a plurality of UEs, a plurality of second PRACHs indicating second requests for a second SIB1; transmitting a second response to the plurality of second PRACHs; and refraining from transmitting the second SIB1 in response to determining that each of the plurality of UEs failed to receive or decode the second response.

[0221] Clause 21. The method of any one of clauses 16-20, further comprising: determining a number of SIB1 repetitions based at least one of: a first number of repetitions configured via radio resource control (RRC) signaling, a second number of repetitions configured in the response to the first PRACH, a third predefined number of repetitions, a fourth number of repetitions indicated by a physical downlink control channel (PDCCH) scheduling a physical downlink shared channel (PDSCH) for the SIB1 repetitions, or a fifth number of repetitions based on a beam quality; and transmitting repetitions of the first SIB1 based on the number of SIB1 repetitions.

[0222] Clause 22. The method of one of clauses 16-21, further comprising: determining at least one of a downlink control information (DCI) size or a frequency domain resource assignment (FDRA) based on at least one of: a first bandwidth configured for a control resource set (CORESET) ; a second bandwidth configured for a downlink bandwidth part (BWP) ; a third bandwidth of an SSB associated with the first PRACH; a fourth bandwidth included in the SSB configuration; or a fifth bandwidth based on the one or more of a location of the SSB or a carrier frequency of a cell including the network entity.

[0223] Clause 23. An apparatus, comprising: a communication unit; and a processing system configured to control the communication unit to implement any one of the methods of any one of clauses 1-22.

[0224] Aspects of the subject matter described in this disclosure can be implemented as a computer-readable medium having stored therein instructions which, when executed by a processor, causes the processor to perform any one of the above-mentioned functionalities.  Aspects of the subject matter described in this disclosure can be implemented as a system having means for implementing any one of the above-mentioned functionalities. Aspects of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any one of the above-mentioned functionalities.

[0225] The following additional considerations may apply to the foregoing and the following discussions. Generally speaking, description for one of the above figures can apply to another of the above figures. Any event or block described above can be optional. For example, an event or block with dashed lines can be optional. In some implementations, “message” is used and can be replaced by “information element (IE) , ” and vice versa. In some implementations, “IE” is used and can be replaced by “field, ” and vice versa. In some implementations, “subband” can be replaced with “sub-band. ” In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters, ” and vice versa. In some implementations, “some” means “one or more. ” In some implementations, “at least one” means “one or more. ” The “eNB” can be replaced by “base station, ” “gNB, ” “6G base station, ” “evolved gNB, ” or 6G gNB. “MME” can be replaced by AMF or evolved AMF or 6G AMF. “Core network (CN) ” can be replaced by EPC, 5GC or 6GC.

[0226] Unless defined otherwise, technical and scientific terms used herein have the same meaning as is commonly understood by one of ordinary skill in the art to which this specification belongs. The terms “first, ” “second, ” and the like, as used herein do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The use of terms “including, ” “comprising” or “having” and variations thereof herein are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms “connected” and “coupled” are not restricted to physical or mechanical connections or couplings and can include electrical connections or couplings, whether direct or indirect. Furthermore, terms “circuit” and “circuitry” and “control unit” may include either a single component or a plurality of components, which are either active and / or passive and are connected or otherwise coupled together to provide the described function. In addition, the term operationally coupled as used herein includes wired coupling, wireless coupling, electrical coupling, magnetic coupling, radio communication, software based communication, or combinations thereof.

[0227] Some or all of the foregoing or the following implementations can be jointly combined or formed to be a new or another one implementation. The foregoing or the following techniques can be used to solve at least (but not limited to) the issue (s) or scenario (s) mentioned in this disclosure. Any two or more than two of the foregoing or the following paragraphs, (sub) -bullets, points, actions, or claims described in each method / technique / implementation may be combined logically, reasonably, and properly to form a specific method. Any sentence, paragraph, (sub) -bullet, point, action, or claim described in each of the foregoing or the following technique (s)  / implementation (s)  / concept (s) may be implemented independently and separately to form a specific method. Dependency, such as “based on, ” “more specifically, ” “where” or etc., in technique (s)  / implementation (s)  / concept (s) mentioned in this disclosure is just one possible implementation which would not restrict the specific method.

[0228] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE) , ” and vice versa. In some implementations, “IE” is used and can be replaced by “field, ” and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters, ” and vice versa. In some implementations, “some” means “one or more. ” In some implementations, “at least one” means “one or more. ”

[0229] As used herein, the terms “user device” , “user equipment” (for example, UE 102A) , “wireless communication device” , “mobile communication device” , “communication device” , or “mobile device” refer to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Internet-of-Things (IoT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media-streaming dongles or another personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, broadband routers or other types of routers, and similar electronic devices which include a programmable processor  and memory and circuitry configured to perform operations as described herein. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS) . Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID) . Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0230] Certain techniques are described in this disclosure as including logic or a number of components or modules. Modules can be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) , a digital signal processor (DSP) , etc. ) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0231] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

[0232] As used herein, the terms “component” and “module” are intended to be broadly construed as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly construed to mean “based at least in part on. ”

[0233] As used herein, a phrase referring to a list of items separated by “or” refers to any combination of those items, including single members. For example, “a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0234] In this disclosure, an expression of “X / Y” may include meaning of any of the following: “X or Y” or “X and Y” or “X and / or Y. " An expression of “ (A) B” or “B (A) ” may include concept of “only B. ” An expression of “ (A) B” or “B (A) ” may include concept of “A+B” or “B+A. ”

[0235] In this disclosure, the term "can" indicates a capability, or alternatively indicates a possible implementation option. The term "may" indicates a permission or a possible implementation option.

[0236] Some aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like. It is noted that “below” and “less than” may include the value being less than or equal to the threshold. Similarly, a value that is described as being “above” or “greater than” a threshold may include a value that is greater than or equal to the threshold.

[0237] The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.

[0238] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-executable or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or to control the operation of, a data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage  or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.

[0239] Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0240] Additionally, various features that are described in this specification in the context of separate implementations also can be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0241] The drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results.

[0242] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination  of aspects from any of the examples is also within the scope of the disclosure. The examples in this disclosure are provided for pedagogical purposes.

Claims

1.A method for wireless communication by a user equipment (UE) (102A, 102B, 1702) , the method comprising:receiving (310, 1310, 1510) , from a first network entity (104A, 1704) or a second network entity (104B, 1704) , a random access channel (RACH) configuration (431) for requesting a system information block type 1 (SIB1) in association with a synchronization signal block (SSB) configuration, the RACH configuration including at least one of one or more random access channel occasion (RO) selection parameters or one or more preamble selection parameters; andtransmitting (360, 1360, 1560) , to the first network entity, a first physical random access channel (PRACH) indicating a first SIB1 request for the SIB1 using at least one RO based on the one or more RO selection parameters or at least one preamble based on the one or more preamble selection parameters.2.The method of claim 1, further comprising selecting at least one RO based on the one or more RO selection parameters or at least one preamble based on the one or more preamble selection parameters.3.The method of claim 2, further comprising at least one of:monitoring, during a first monitoring window after the transmitting the first SIB1 request, for a random access response (RAR) to the first PRACH;monitoring for the SIB1 during a second monitoring window based on a reception of the RAR in the first monitoring window; ormonitoring for the SIB1 during a third monitoring window different from the second monitoring window based on a failure to receive the RAR in the first monitoring window.4.The method of claim 3, further comprising:monitoring for the SIB1 during a fourth monitoring window that starts after the first PRACH and ends on or before a start of the second monitoring window.5.The method of claims 3 or 4, further comprising at least one of:transmitting (364, 1364) a first acknowledgement (ACK) to the RAR;transmitting (364.1364) a first negative acknowledgment (NACK) to the RAR;transmitting (382, 1382) a second ACK to the SIB1; ortransmitting (382, 1382) a second NACK to the SIB1.6.The method of claims 3 or 4, further comprising at least one of:refraining from retransmitting the first PRACH when the RAR includes an indication that the first network entity will refrain from transmitting the SIB1; orrefraining from transmitting a second PRACH indicating a second SIB1 request based on a SIB1 broadcast status.7.The method of any one of claims 1-6, wherein at least one of:the at least one RO is included in a first subset of a plurality of ROs configured for on-demand SIB1 request and a second subset of the plurality of ROs is configured for a purpose other than an on-demand SIB1 request; orthe at least one preamble is included in a first subset of a plurality of preambles configured for the on-demand SIB1 request and a second subset of the plurality of preambles is configured for the purpose other than the on-demand SIB1 request.8.The method of any one of claims 1-7, further comprising:transmitting the first PRACH based on a first configuration of power control parameters; andtransmitting at least one other PRACH based on a second configuration of power control parameters different from the first configuration of power control parameters, the second configuration for a PRACH transmission other than an on-demand SIB1 request.9.The method of any one of claims 1-8, further comprising:transmitting the first PRACH based on a first power level indicated in a power control configuration; andretransmitting the first PRACH based on a power ramping step indicated in the power control configuration.10.The method of any one of claims 1-9, further comprising receiving an SSB based on the SSB configuration, wherein the transmitting the first PRACH is based on one or more triggering conditions being satisfied, and wherein the one or more triggering conditions include at least one of:a synchronization signal reference signal received power (SS-RSRP) for the SSB is greater than a first threshold;a synchronization signal signal-to-noise and interference ratio (SS-SINR) for the SSB is greater than a second threshold;a synchronization signal reference signal received quality (SS-RSRQ) for the SSB is greater than a third threshold; ora pathloss measured based on the SSB is smaller than a fourth threshold.11.The method of any one of claims 1-10, wherein the transmitting the first PRACH includes transmitting repetitions of the first PRACH based on a configured number of repetitions and a downlink quality threshold.12.The method of any one of claims 1-11, further comprising:receiving, from the first network entity, a configuration of one or more association periods, the association periods based on a periodicity of ROs, wherein the transmitting the first PRACH includes transmitting the first PRACH within one of the one or more association periods.13.The method of any one of claims 1-12, wherein the preamble selection parameters include beam quality range parameters, the method further comprising:determining a beam quality; andselecting a preamble based on the beam quality and the beam quality range parameters, wherein the transmitting the first PRACH uses the selected preamble.14.A method for wireless communication by a network (104A, 104B, 1704) entity, the method comprising:transmitting (310, 1410, 1610) , to a user equipment (UE) (102A, 102B, 1702) , a random access channel (RACH) configuration (431) for requesting a system information block type 1 (SIB1) in association with a synchronization signal block (SSB) configuration, the RACH configuration including at least one of one or more random access channel occasion (RO) selection parameters or one or more preamble selection parameters;receiving (360, 1460, 1660) , from the UE, a first physical random access channel (PRACH) indicating a first SIB1 request for a first SIB1;transmitting (362, 1462, 1662) , to the UE, a response to the first PRACH; andtransmitting (380, 1480, 1680) , to the UE, the first SIB1.15.The method of claim 14, wherein the transmitting the response to the first PRACH includes transmitting at least one of:a random access response (RAR) that omits a medium access control (MAC) header and includes a first MAC sub-header;a second MAC sub-header that omits a random access preamble identifier (RAPID) ; orthe second MAC sub-header with a type field indicating the second MAC sub-header omits the RAPID.16.The method of any one of claims 14 or 15, further comprising:refraining from retransmitting the first SIB1 in response to determining that each of a plurality of UEs requesting the first SIB1 received the first SIB1.17.The method of any one of claims 14-16, further comprising:receiving, from a plurality of UEs, a plurality of second PRACHs indicating second requests for a second SIB1;transmitting a second response to the plurality of second PRACHs; andrefraining from transmitting the second SIB1 in response to determining that each of the plurality of UEs failed to receive or decode the second response.18.The method of any one of claims 14-17, further comprising:determining a number of SIB1 repetitions based at least one of:a first number of repetitions configured via radio resource control (RRC) signaling,a second number of repetitions configured in the response to the first PRACH,a third predefined number of repetitions,a fourth number of repetitions indicated by a physical downlink control channel (PDCCH) scheduling a physical downlink shared channel (PDSCH) for the SIB1 repetitions, ora fifth number of repetitions based on a beam quality; andtransmitting repetitions of the first SIB1 based on the number of SIB1 repetitions.19.An apparatus, comprising:a communication unit; anda processing system configured to control the communication unit to implement any one of the methods of any one of claims 1-18.

Images