Beam based random access channel occasion configuration for non-terrestrial network

Abstract

An apparatus configured to process, based on signals received from a base station, random-access channel (RACH) configuration information comprising RACH occasion (RO) configuration information for a non-terrestrial network (NTN), process, based on signals received from the base station, updated RACH configuration information comprising updated RO configuration information for the NTN and perform a RACH procedure using the updated RACH configuration information.

Description

Beam Based Random Access Channel Occasion Configuration For Non-Terrestrial NetworkBackground

[0001] A user equipment (UE) may establish a connection to at least one of multiple different networks or types of networks, e.g., a public land mobile network (PLMN) operating a radio access network (RAN) . A non-terrestrial network (NTN) refers to a network utilizing non-terrestrial components, e.g., one or more satellites, to provide UE access to a PLMN. It has been identified that there is a need for NTN system level enhancements related to the random-access channel (RACH) that provide benefits for network energy saving.Summary

[0002] Some example embodiments are related to an apparatus having processing circuitry configured to process, based on signals received from a base station, random-access channel (RACH) configuration information comprising RACH occasion (RO) configuration information for a non-terrestrial network (NTN) , process, based on signals received from the base station, updated RACH configuration information comprising updated RO configuration information for the NTN and perform a RACH procedure using the updated RACH configuration information.

[0003] Some example embodiments are related to an apparatus having processing circuitry configured to generate, for transmission to a user equipment (UE) , random-access channel (RACH) configuration information comprising RACH occasion (RO) configuration information for a non-terrestrial network (NTN) , modify a RO configuration for one or more ROs and generate, for  transmission to the UE, updated RACH configuration information comprising updated RO configuration information for the NTN to the UE.Brief Description of the Drawings

[0004] Fig. 1 shows an example network arrangement according to various example embodiments.

[0005] Fig. 2 shows an example user equipment (UE) according to various example embodiments.

[0006] Fig. 3 shows an example base station according to various example embodiments.

[0007] Fig. 4 shows an example non-terrestrial network (NTN) architecture according to various example embodiments.

[0008] Fig. 5 shows a method for dynamic configuration updated according to various example embodiments.

[0009] Fig. 6 shows a method for dynamic RACH configuration update according to various example embodiments.

[0010] Fig. 7 shows examples of random-access channel (RACH) occasion (RO) relaxation according to various example embodiments.

[0011] Fig. 8 shows an example abstract notation one (ASN. 1) for a RACH-occasion-periodicityAndOffset field of a RACH-ConfigCommon information element (IE) according to various example embodiments.

[0012] Fig. 9 shows an example of an NTN component with a beam group-based RACH configuration according to various example embodiments.

[0013] Fig. 10 shows a method for RO update according to various example embodiments.

[0014] Fig. 11 shows a method for RO update according to various example embodiments.Detailed Description

[0015] The example embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The example embodiments relate to the random access channel (RACH) in a non-terrestrial network (NTN) .

[0016] The example embodiments are described with regard to a user equipment (UE) . However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component.

[0017] The example embodiments are also described with regard to a 5G New Radio (NR) network. However, reference to a 5G NR network is merely provided for illustrative purposes. The example embodiments may be utilized with any network that may  establish a connection to a UE and exchange information and data with the UE (e.g., 5G-Advanced networks, 6G networks, etc. ) .

[0018] The example embodiments are further described with regard to a 5G NR network integrated with a non-terrestrial-network (NTN) utilizing one or more satellites to provide UE access to the 5G NR radio access network (RAN) . A satellite-based NTN may be deployed by a public land mobile network (PLMN) and may be further integrated with a terrestrial network (TN) of the PLMN. Throughout this description, the non-terrestrial component is generally described as a satellite. However, any reference to a satellite is only for illustrative purposes and the example embodiments may apply to other types of non-terrestrial components, e.g., airplanes, unmanned aerial vehicles (UAVs) , etc.

[0019] A RACH procedure may be used by the UE to synchronize with the network and access network services. For example, the UE may transmit a preamble to the network during a RACH occasion (RO) over a physical random-access channel (PRACH) . The RO may represent durations of time during which the network monitors for preambles transmitted by UEs. In response to the preamble, the network may send a random-access response (RAR) to the UE comprising information to continue the synchronization process.

[0020] The example embodiments introduce enhancements for dynamic RACH configurations that allow the network to adapt to the user activity and save energy. According to some aspects, the example embodiments introduce mechanisms for RO relaxation in the time domain and RO relaxation in the spatial domain. In addition, the example embodiments introduce signaling techniques  to support dynamic RACH configurations. Each of these example embodiments will be descried in more detail below. The example embodiments described herein may be used independently from one another, in conjunction with currently implemented RACH related mechanisms, in conjunction with future implementations of RACH related mechanisms or independently from other RACH related mechanisms.

[0021] Fig. 1 shows an example network arrangement 100 according to various example embodiments. The example network arrangement 100 includes a UE 110. The UE 110 may be any type of electronic component that is configured to communicate via a network, e.g., mobile phones, tablet computers, desktop computers, smartphones, phablets, embedded devices, wearables, Internet of Things (IoT) devices, etc. the example of a single UE 110 is merely provided for illustrative purposes. An actual network arrangement may include any number of UEs being used by any number of users.

[0022] The UE 110 may be configured to communicate with one or more networks. In the example of the network arrangement 100, the network with which the UE 110 may wirelessly communicate is a 5G NR radio access network (RAN) 120. However, the UE 110 may also communicate with other types of networks (e.g., 5G cloud RAN, a next generation RAN (NG-RAN) , a long-term evolution (LTE) RAN, a legacy cellular network, a wireless local area network (WLAN) , etc. ) and the UE 110 may also communicate with networks over a wired connection. With regard to the example embodiments, the UE 110 may establish a connection with the 5G NR RAN 120. Therefore, the UE 110 may have a 5G NR chipset to communicate with the NR RAN 120.

[0023] The 5G NR RAN 120 may be a portion of a public land mobile network (PLMN) that may be deployed by a network carrier (e.g., Verizon, AT&T, T-Mobile, etc. ) . The 5G NR RAN 120 may include, for example, nodes or base stations (Node Bs, eNodeBs, HeNBs, eNBS, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc. ) that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set.

[0024] In the network arrangement 100, the 5G NR RAN 120 includes a base station (e.g., gNB 120A) that may be in a terrestrial network (TN) deployment or a non-terrestrial network (NTN) deployment. For example, a satellite-based system may be integrated with the 5G NR RAN 120 to provide network access to the UE 110 in the NTN deployment and the base station may, in some cases, be located on a non-terrestrial component, e.g., a satellite. An example NTN network architecture will be described in greater detail below with reference to Fig. 4.

[0025] Returning to the network arrangement 100 of Fig. 1, the gNB 120A may include one or more communication interfaces to exchange data and / or information with the UE 110, the corresponding 5G NR RAN 120, the cellular core network 130, the internet 140, etc.

[0026] The UE 110 may connect to the 5G NR-RAN 120 via the gNB 120A. Any association procedure may be performed for the UE 110 to connect to the 5G NR-RAN 120. For example, as discussed above, the 5G NR-RAN 120 may be associated with a particular cellular provider where the UE 110 and / or the user thereof has a contract and credential information (e.g., stored on a SIM card) . Upon detecting the presence of the 5G NR-RAN 120, the UE  110 may transmit the corresponding credential information to associate with the 5G NR-RAN 120. More specifically, the UE 110 may associate with a specific cell (e.g., the gNB 120A) . However, as mentioned above, reference to the 5G NR-RAN 120 is merely for illustrative purposes and any appropriate type of RAN may be used.

[0027] In addition to the 5G NR RAN 120, the network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 may be considered to be the interconnected set of components that manages the operation and traffic of the cellular network. The cellular core network 130 also manages the traffic that flows between the cellular network and the Internet 140.

[0028] The IMS 150 may be generally described as an architecture for delivering multimedia services to the UE 110 using the IP protocol. The IMS 150 may communicate with the cellular core network 130 and the Internet 140 to provide the multimedia services to the UE 110. The network services backbone 160 is in communication either directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 may be generally described as a set of components (e.g., servers, network storage arrangements, etc. ) that implement a suite of services that may be used to extend the functionalities of the UE 110 in communication with the various networks.

[0029] Fig. 2 shows an example UE 110 according to various example embodiments. The UE 110 will be described with regard to the network arrangement 100 of Fig. 1. The UE 110 may include a  processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225 and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a power supply, a data acquisition device, ports to electrically connect the UE 110 to other electronic devices, etc.

[0030] The processor 205 may be configured to execute a plurality of engines of the UE 110. For example, the engines may include an NTN RACH engine 235. The NTN RACH engine 235 may perform various operations related to communicating with the NTN using the RACH such as, but not limited to, receiving RACH configuration information, updating RACH configuration information and transmitting a signal to the NTN during a RACH occasion.

[0031] The above referenced engine 235 being an application (e.g., a program) executed by the processor 205 is merely provided for illustrative purposes. The functionality associated with the engine 235 may also be represented as a separate incorporated component of the UE 110 or may be a modular component coupled to the UE 110, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. The engine 235 may also be embodied as one application or separate applications. In addition, in some UEs, the functionality described for the processor 205 is split among two or more processors such as a baseband processor and an applications processor. The example embodiments may be implemented in any of these or other configurations of a UE.

[0032] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to show data to a user while the I / O device 220 may be a hardware component that enables the user to enter inputs. The display device 215 and the I / O device 220 may be separate components or integrated together such as a teuchscreen.

[0033] The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120, an LTE-RAN (not pictured) , a legacy RAN (not pictured) , a WLAN (not pictured) , etc. Accordingly, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . The transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive from and / or transmit signals to the transceiver 225. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any one of the methods described herein.

[0034] Fig. 3 shows an example base station 300 according to various example embodiments. The base station 300 may represent the gNB 120A or any other type of access node through which the UE 110 may establish a connection and manage network operations.

[0035] The base station 300 may include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a transceiver 320, and other components 325. The other components 325 may include, for example, an audio input device, an audio output device, a battery, a data acquisition device, ports to electrically connect the base station 300 to other electronic devices and / or power sources, antenna elements, antenna panels, etc.

[0036] The processor 305 may be configured to execute a plurality of engines for the base station 300. For example, the engines may include an NTN RACH engine 330. The NTN RACH engine 330 may perform various operations related to communicating with UEs over the RACH such as, but not limited to, transmitting RACH configuration information to the UE 110, triggering a RACH configuration update and monitoring RACH occasions.

[0037] The above noted engine 330 being an application (e.g., a program) executed by the processor 305 is only an example. The functionality associated with the engine 330 may also be represented as a separate incorporated component of the base station 300 or may be a modular component coupled to the base station 300, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. In addition, in some base stations, the functionality described for the processor 305 is split among a plurality of processors (e.g., a baseband processor, an applications processor, etc. ) . The example embodiments may be implemented in any of these or other configurations of a base station.

[0038] The memory arrangement 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 may be a hardware component or ports that enable a user to interact with the base statien 300.

[0039] The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UEs in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . Therefore, the transceiver 320 may include one or more components to enable the data exchange with the various networks and UEs. The transceiver 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive from and / or transmit signals to the transceiver 320. The processor 305 may be configured to encode and / or decode signals (e.g., signaling from a UE) for implementing any one of the methods described herein.

[0040] Fig. 4 shows an example non-terrestrial network (NTN) architecture 400 according to various example embodiments. An NTN may relate to any network using non-terrestrial components, such as satellites, airplanes, unmanned aerial vehicles (UAVs) , etc., to provide network services to a user terminal.

[0041] The NTN architecture 400 represents a network arrangement including one or more satellites, which in this example shows two satellite 410 and 420 that are integrated with  a radio access network (RAN) 440. The RAN 440 may be, for example, the 5G NR RAN 120 described above with respect to Fig. 1. The NTN architecture 400 includes a gateway 430 connecting the RAN 440 with the NTN components. In the NTN architecture 400 of Fig. 4, the gateway 430 and the satellites 410 and 420 communicate via feeder links 412, 422. In some NTN deployments, satellites may be served by several gateways simultaneously.

[0042] The satellites 410 and 420 provide network services to a UE 110 via a service link (not shown) . The satellites 410 and RAN 420 may implement either a transparent payload or a regenerative payload. A transparent payload refers to an arrangement where the satellites 410 and 420 receive signals and transmit an amplified version of the signal, with a frequency conversion. For example, the satellite 410 may receive uplink communications from the UE 110 on service link frequencies and transmit an amplified version of the signal to the gateway 430 on feeder link frequencies or may receive downlink communications via the gateway 430 on feeder link frequencies and transmit an amplified version of the signal to the UE 110 on service link frequencies. A regenerative payload refers to an arrangement where the satellites 410 and 420 act as a distributed unit (DU) or a base station (e.g., a gNB) , wherein received signals are regenerated with signal-processing techniques (e.g., demodulation, decoding, switching, encoding, modulation, etc. ) before being re-transmitted.

[0043] The example NTN architecture 400 shown in Fig. 4 is not intended to limit the example embodiments in any way. NTNs may be integrated with the 5G NR RAN and / or other networks in any one of a variety of manners. For example, a typical satellite-based NTN may comprise a low earth orbit (LEO)  constellation including an array of satellites and gateways with broad interconnectivity via ground-to-ground station (G2G) links, satellite-to-satellite (S2S) links, ground-to-satellite (G2S) links, and satellite-to-ground (S2G) links. Other types of satellite-based NTNs include geostationary-orbiting (GEO) satellites or medium-earth-orbiting (MEO) satellites.

[0044] The different types of NTNs each have respective strengths and weaknesses and may be deployed in a variety of scenarios, depending on the goal to be achieved, e.g., broad coverage across a large region, concentrated coverage in an urban environment or along a highly trafficked route, etc. Thus, the NTN architecture 400 described in Fig. 4 is merely provided for illustrative purposes.

[0045] Fig. 5 shows a method 500 for dynamic RACH configuration update according to various example embodiments. The method 500 is described from the perspective of the network. The UE 110 side of this procedure is described below with regard to the method 600 of Fig. 6.

[0046] In 505, the network transmits a synchronization signal block (SSB) and RACH configuration information. For example, a base station may transmit a RACH-ConfigCommon information element (IE) in a system information block 1 (SIB1) . The RACH configuration information may indicate a RO periodicity and / or other parameters related to a RACH procedure.

[0047] In 510, the network determines that a RO is being used infrequently. For example, the network may determine that UEs have not used a particular RO a predetermined number of times during a time window. This may indicate that a RO is not being  used often enough to justify the power used by the network to monitor the RO at its current periodicity.

[0048] In 515, the network increases the periodicity of the RO. By increasing the periodicity of the RO, the network is able to save power because the network expends less resources monitoring the RO.

[0049] In 520, the network transmits an SSB and updated RACH configuration information. The updated RACH configuration information may be provided in, for example, a SIB1, a new SIB introduced for this purpose or any other appropriate type of message.

[0050] Fig. 6 shows a method 600 for dynamic RACH configuration update according to various example embodiments. The method 600 is described from the perspective of the UE 110.

[0051] In 605, the UE 110 receives an SSB and RACH configuration information. For example, the RACH configuration information may be provided in a SIB1 with RACH-ConfigCommon IE. The UE 110 may perform a RACH procedure using information received in 605.

[0052] In 610, the UE 110 receives updated RACH configuration information. For example, as indicated above in the method 500, the network may determine that it would be beneficial to change the configuration of one or more ROs. In 615, the UE 110 may perform a RACH procedure using the updated RACH configuration information.

[0053] Fig. 7 shows examples of RACH occasion relaxation according to various example embodiments. Examples 710, 740 and 760 are described with regard to SSBs 1-4 and ROs 1-4 where SSB 1 is associated with RO 1, SSB 2 is associated with RO 2, SSB 3 is associated with RO 3 and SSB 4 is associated with RO 4.

[0054] Example 710 illustrates an example of legacy operation where SSBs 1-4 are transmitted during time windows 712-718 and ROs 1-4 are scheduled during time windows 722-728.

[0055] Example 740 illustrates an example of cell-based RO periodicity adaptation where SSBs 1-4 are transmitted during time windows 742-748 and ROs 1-4 are scheduled during time windows 752 and 756. During time windows 754 and 758 the network has an opportunity to save power because the network does not have to monitor ROs 1-4.

[0056] Initially, consider a scenario where the network uses legacy operation (e.g., example 710) during a first time period. As indicated in the description of the method 500, the network may determine that network energy saving techniques may be implemented based on activity during the first time period. In example 740, the network implements RO relaxation in the time domain by increasing the periodicity with which ROs 1-4 are scheduled to occur. Thus, compared to example 710, ROs 1-4 do not occur as often and the network may be able to save power because the network does not need to expend energy monitoring ROs 1-4 during time windows 754 and 758.

[0057] Example 760 illustrates an example of SSB-based RO periodicity adaptation where SSBs 1-4 are transmitted during  time windows 762-768, ROs 1-4 are scheduled during time windows 772 and 776 and ROs 1-3 are scheduled during time windows 774 and 778. In this example, the network has an opportunity to save power during time windows 774 and 778 because the network does not have to monitor RO 4.

[0058] Initially, consider a scenario where the network uses legacy operation (e.g., example 710) during a first time period. As indicated in the description of the method 500, the network may determine that network energy saving techniques may be implemented based on activity during the first time period. SSBs 1-4 may be beams transmitted in different directions and thus, ROs 1-4 also correspond to different directions. In example 760, the network implements RO relaxation in the spatial domain by increasing the periodicity with which RO 4 is scheduled to occur because the network has determined that the activity associated with the spatial direction of RO 4 is being used infrequently. Thus, compared to example 710, RO 4 does not occur as often and the network may be able to save power because the network does not need to expend energy monitoring RO 4 during time windows 774 and 778.

[0059] According to some aspects, the example embodiments may use an SSB-based RACH configuration. With this approach, the RO periodicity and location may be configured per SSB. In some examples, the location of the RO may be based an offset from its corresponding SSB.

[0060] The example embodiments introduce an additional field for the RACH-ConfigCommon IE. Throughout this description, this field may be referred to as "RACH-occasion- periodicityAndOffset. " Fig. 8 shows an example abstract notation one (ASN. 1) for the RACH-occasion-periodicityAndOffset field of the RACH-ConfigCommon IE according to various example embodiments.

[0061] Using a PRACH configuration index, the RO periodicity may be updated by multiplying the original RO periodicity with a choice value in the RACH-occasion-periodicityAndOffset for the corresponding SSB. The value of the RO offset may be updated by summing the original RO offset with the integer value in the RACH-occasion-periodicityAndOffset times the original periodicity for the corresponding SSB.

[0062] According to some aspects, the example embodiments may use a beam group-based RACH configuration. Fig. 9 shows an example of an NTN component with a beam group-based RACH configuration according to various example embodiments. In this example, the NTN component 910 is a satellite, however, the example embodiments are not limited to this type of NTN component and may be used with any appropriate type of NTN component.

[0063] The NTN component 905 may transmit SSB 1, SSB 2, SSB3 and SSB 4. SSB 1 may be transmitted using beam 1 and beam 5, SSB 2 may be transmitted using beam 2 and beam 6, SSB 3 may be transmitted using beam 3 and beam 7 and SSB 4 may be transmitted using beam 4 and beam 8. The beams are then grouped into group 1, group 2 and group 3 as shown in the table 920. However, the example of a 4 SSBs, 8 beams and 3 groups is merely provided for illustrative purposes. The example embodiments may any appropriate number of SSBs, beams and groups.

[0064] In this example, group 1 includes beams 1 and 5 of SSB 1, beam 2 of SSB 2, beam 3 of SSB 3 and beam 8 of SSB 4. Group 2 includes beam 6 of SSB 2 and beam 4 of SSB 4. Group 3 includes beam 7 of SSB 3. The grouping may be based on one or more parameters indicating a user demand and / or likelihood that the corresponding SSB will be used for random access. In this example, group 1 may include the SSBs most likely to be used for random access, group 2 may include SSBs that are less likely to be used for random access compared to group 1, and group 3 may include SSBs that are less likely to be used for random access compared to group 2.

[0065] The RACH configuration for each group may vary. This may allow the network to use RO relaxation per group. In this example, since groups 2 and 3 are less likely to be used for random access, the network may apply RO relaxation to the RACH configuration for group 2 and RO relaxation to the RACH configuration for group 3. By increasing the periodicity of the ROs associated for each group, the network has the opportunity to save power without altering the ROs that are most likely to be used for random access.

[0066] The RACH configuration information for each group may be indicated to UEs. The beam group-based RACH configuration information may be provided to UEs via a SIB. The SIB may be a SIB19, a new SIB introduced for this purpose, SIB 1 or any other appropriate type of SIB.

[0067] The beams within each group and / or the RACH configuration information for each group may be changed to adapt  to the observed or expected network activity. In one example, any group allocation information update may trigger the SIB notification for entire cell covered by the NTN component. For instance, if beam 6 is moved from group 2 to group 1. The NTN component 905 may transmit a SIB over the entire cell providing the updated beam group-based RACH configuration information. In another example, any group allocation information update may trigger the SIB notification for corresponding beam only. For instance, if beam 6 is moved from group 2 to group 1. The NTN component 905 may transmit a SIB on only beam 6 cell providing the updated beam group-based RACH configuration information. In some embodiments, a SIB1 with a changed "systemInfoValueTag" value may only be sent over a specific beam indicating the change to the group-based RACH configuration.

[0068] In other examples, dedicated radio resource control (RRC) message may be used to provide an indication of the updated beam group-based RACH configuration. In another example, SIB 1 may be used to provide an indication of the updated beam group-based RACH configuration.

[0069] According to some aspects, the example embodiments introduce signaling for a RO update. Fig. 10 shows a method 1000 for RO update according to various example embodiments. The method 1000 is described from the perspective of the UE 110.

[0070] In 1005, the UE 110 receives RACH configuration information via SIB1. The RACH configuration information may indicate to the UE 110 ROs the UE 110 may use for random access.

[0071] In 1010, receives a paging message. For example, the UE 110 may be in an RRC idle or inactive state and receive paging message with an indication of a system information modification. This indication may be provided by setting the field systemInfoModification to true or in any other appropriate manner. The paging message may cause the UE 110 to attempt to receive a SIB1 from the network.

[0072] In 1015, the UE 110 receives SIB1. The SIB1 may indicate to the UE 110 that there has been an update to the system information. This indication may be provided by updated a system information value or in any other appropriate manner. The paging message may cause the UE 110 to attempt to receive a SIB that carries the updated RACH configuration information. The SIB may be a SIB19, a new SIB introduced for RACH configuration information update or any other appropriate type of SIB.

[0073] In 1020, the UE 110 receives a SIB with updated RACH configuration information that is different than the RACH configuration information provided in SIB1. For example, if the network has decided to implement RO relaxation, the updated RACH configuration information may indicate a different RO periodicity. In 1025, the UE 110 applies the updated RACH configuration information. If a RACH procedure is triggered after the 1025, the UE 110 may use the updated RACH configuration information for random access.

[0074] In the example provided above, the paging may use a short message with a legacy code point (e.g., systemInfoModification) . In other embodiments, a new code point may be introduced to indicate a RACH configuration update. In  this example, this new code point may be referred to as "RACHConfigModification. " However, reference to RACHConfigModification is merely provided for illustrative purposes. Different entities may refer to a similar concept by a different name.

[0075] In response to the new code point, the UE 110 may attempt to receive the SIB with the updated RACH configuration information. To provide an example within the context of the method 1000, the UE 110 may receive the paging message with the new code point in 1010. The UE 110 may then attempt to receive the SIB in 1020 and skip the SIB1 received in 1015.

[0076] Fig. 11 shows a method 1100 for RO update according to various example embodiments. The method 1100 is described from the perspective of the UE 110. In this example, downlink control information (DCI) may be used to cause the UE 110 to attempt to receive a SIB with the updated RACH configuration information.

[0077] In 1105, the UE 110 receives RACH configuration information via SIB1. The RACH configuration information may indicate to the UE 110 ROs the UE 110 may use for random access.

[0078] In 1110, receives a group common DCI. For example, the UE 110 may be in an RRC idle or inactive state and receive the group common DCI indicating a RACH configuration update. In some embodiments, a new group common DCI format may be used to provide this indication. Throughout this description, the new DCI format may be referred to as DCI format 2_10. However, reference to DCI format 2_10 is merely provided for illustrative  purposes. Different entities may refer to a similar concept by a different name.

[0079] The DCI may be an SSB beam based indication where each bit in the DCI corresponds to an SSB beam. If the RACH configuration for a particular beam has been changed, the corresponding bit in the DCI may be set to a first value (e.g., 1) , otherwise, the bit is set to a second value (e.g., 0) .

[0080] In 1115, the UE 110 receives a SIB with RACH the updated RACH configuration information. For example, if the network has decided to implement RO relaxation, the updated RACH configuration information may indicate a different RO periodicity. In 1120, the UE 110 applies the updated RACH configuration information. If a RACH procedure is triggered after the 1120, the UE 110 may use the updated RACH configuration information for random access.

[0081] In some embodiments, the network may use existing group common DCI to indicate to the UE 110 that the RACH configuration has been updated. In one example, DCI format 2_9 may include an indication for cell discontinuous transmission (DTX) and / or discontinuous reception (DRX) activation / deactivation and an indication of the RO update. In another example, the DCI format 2_9 may indicate DTX / RX activation / deactivation when scrambled with a first type of a radio network temporary identifier (RNTI) . However, when the DCI is scrambled with a second different type of RNTI, DCI format 2_9 is configured to indicate the RO update. Throughout this description, this type of RNTI may be referred to as RACH-RNTI. However, reference to RACH-RNTI is merely provided for  illustrative purposes. Different entities may refer to similar concepts by a different name.

[0082] According to some aspects, RO configuration may be updated in SIB1. With this approach, the network may send a SIB1 with a RACH-ConfigCommon field that includes the updated RACH configuration information. In one example, no other notification regarding the updated RACH configuration information is provided. In other examples, the network may send a paging message to the UE 110 indicating that SIB1 has updated RACH configuration information. In response to the paging message, the UE 110 receives the SIB 1 with the updated RACH configuration information.

[0083] In another example, the network may send group common DCI format 2_10 to the UE 110 indicating that SIB1 has updated RACH configuration information. This indication may be a SSB beam based indication where bits in the DCI correspond to different beams. If the RACH configuration for a beam is changed, the corresponding bit in the DCI may be set to a first value (e.g., 1) . Otherwise, the corresponding bit in the DCI may be set to a second value (e.g., 2) . In response to the DCI, the UE 110 receives the SIB 1 with the updated RACH configuration information.

[0084] In another example, the network may send group common DCI format 2_9 to the UE 110 indicating that SIB1 has updated RACH configuration information. The DCI format 2_9 may include an explicit indication that the RACH configuration has been updated or the DCI format 2_9 may be scrambled with RACH-RNTI to indicate that the RACH configuration has been updated. In  response to the DCI, the UE 110 receives the SIB 1 with the updated RACH configuration information.

[0085] According to some aspects, the example embodiments relate to the activation time for the RACH occasion update. In one example, the activation time of the RACH occasion update may be dynamically indicated. The SIB with the RACH configuration update may provide an indication of the activation time of the RACH occasion update. In one example, the format of the activation time may be in coordinated universal time (UTC) time. In another example, the format of the activation time may be based on a system frame number (SFN) or subframe. In addition, the validity duration of the RACH occasion update may also be provided in the SIB.

[0086] In another example, the activation time of RACH occasion update may be configured. With this approach, the SIB may configure the activation time of RACH occasion update where any RACH occasion update is effective at certain SFN values (e.g., when SFN = 0) . The validity duration of RACH occasion update may be valid for a duration of (X) seconds or (Y) SFNs. The SIB may also configure the validity duration of the RACH occasion update.

[0087] In another example, activation time of RACH occasion update may be predefined in third generation partnership project (3GPP) specification. With this approach, the RACH occasion update may be hard encoded to be effective at certain SFN values (e.g., when SFN 0) . The validity of the RACH occasion update may also be predefined.

[0088] Examples

[0089] In a first example, a method comprising processing, based on signals received from a base station, random-access channel (RACH) configuration information comprising RACH occasion (RO) configuration information for a non-terrestrial network (NTN) , processing, based on signals received from the base station, updated RACH configuration information comprising updated RO configuration information for the NTN and performing a RACH procedure using the updated RACH configuration information.

[0090] In a second example, the method of the first example, wherein an RO periodicity and offset is configured per synchronization signal block (SSB) .

[0091] In a third example, the method of the second example, wherein the updated RACH configuration information is received in a field of a RACH-ConfigCommon information element (IE) .

[0092] In a fourth example, the method of the second example, wherein an RO periodicity is updated based on multiplying a first RO periodicity with a choice value from the field of the RACH-ConfigCommon IE.

[0093] In a fifth example, the method of the second example, wherein an RO offset is updated based on summing a first RO offset value with an integer value from the field of the RACH-ConfigCommon IE times a first RO periodicity.

[0094] In a sixth example, the method of the first example, wherein the updated RACH configuration information comprises a beam group-based RACH configuration.

[0095] In a seventh example, the method of the sixth example, wherein the updated RACH configuration information is received in a radio resource control (RRC) message.

[0096] In an eighth example, the method of the sixth example, wherein the updated RACH configuration information is received in a system information block (SIB) .

[0097] In a ninth example, the method of the eighth example, wherein the SIB is a SIB1 with an updated systemInfoValueTag value.

[0098] In a tenth example, the method of the eighth example, wherein the SIB is a SIB19.

[0099] In an eleventh example, the method of the first example, the updated RACH configuration information is processed based on receiving a paging message and a first system information block (SIB) , wherein the updated RACH configuration information is received in a second SIB.

[0100] In a twelfth example, the method of the eleventh example, wherein the paging message includes systemInfoModification set to true.

[0101] In a thirteenth example, the method of the eleventh example, wherein the first SIB includes an updated system infermatien value.

[0102] In a fourteenth example, the method of the eleventh example, wherein the second SIB is a SIB19.

[0103] In a fifteenth example, the method of the first example, wherein the updated RACH configuration information is processed based on receiving a paging message, wherein the updated RACH configuration information is received in a system information block (SIB) .

[0104] In a sixteenth example, the method of the fifteenth example, wherein the paging message includes a short message with a code point configured to indication a RACH configuration medificatien.

[0105] In a seventeenth example, the method of the fifteenth example, wherein the SIB is a SIB19.

[0106] In an eighteenth example, the method of the first example, wherein the updated RACH configuration information is processed based on receiving downlink configuration information (DCI) , wherein the updated RACH configuration information is received in a system information block (SIB) .

[0107] In a nineteenth example, the method of the eighteenth example, wherein the DCI is group common DCI configured to indicate a RACH configuration update for one or more beams.

[0108] In a twentieth example, the method of the nineteenth example, wherein the DCI is DCI format 2_9 comprising an explicit indication of a RACH configuration update.

[0109] In a twenty first example, the method of the eighteenth example, wherein the DCI is DCI format 2_9 scrambled with a radio network temporary identifier configured to indicate a RACH configuration update.

[0110] In a twenty second example, the method of the eighteenth example, wherein the SIB is a SIB19.

[0111] In a twenty third example, the method of the first example, wherein the updated RACH configuration information is received in a system information block 1 (SIB1) .

[0112] In a twenty fourth example, the method of the twenty third example, wherein the SIB1 is processed based on receiving a paging message.

[0113] In a twenty fifth example, the method of the twenty third example, wherein the SIB1 is processed based on receiving a group common DCI.

[0114] In a twenty sixth example, the method of the twenty fifth example, wherein the group common DCI is format 2_9.

[0115] In a twenty seventh example, the method of the first example, wherein the updated RACH configuration information is received in a system information block (SIB) and further comprises an activation time for a RACH occasion (RO) update.

[0116] In a twenty eighth example, the method of the twenty seventh example, wherein the activation time for the RO update is in a coordinated universal time (UTC) format.

[0117] In a twenty ninth example, the method of the twenty seventh example, wherein the activation time for the RO update is based on a subframe or a system frame number (SFN) .

[0118] In a thirtieth example, the method of the twenty seventh example, wherein the SIB further comprises a validity duration of the RO update.

[0119] In a thirty first example, the method of the first example, wherein an activation time for a RACH occasion (RO) update is preconfigured.

[0120] In a thirty second example, the method of the thirty first example, wherein a validity time duration for RO update is preconfigured.

[0121] In a thirty third example, a processor configured to perform any of the methods of the first through thirty second examples.

[0122] In a thirty fourth example, a user equipment (UE) comprising a transceiver configured to communicate with a base station and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the first through thirty second examples.

[0123] In a thirty fifth example, a method comprising generating, for transmission toa user equipment (UE) , random-access channel (RACH) configuration information comprising RACH occasion (RO) configuration information for a non-terrestrial network (NTN) , modifying a RO configuration for one or more ROs and generating, for transmission to the UE, updated RACH configuration information comprising updated RO configuration information for the NTN to the UE.

[0124] In a thirty sixth example, the method of the thirty fifth example, wherein an RO periodicity and offset is configured per synchronization signal block (SSB) .

[0125] In a thirty seventh example, the method of the thirty sixth example, wherein the updated RACH configuration information is provided in a field of a RACH-ConfigCommon information element (IE) .

[0126] In a thirty eighth example, the method of the thirty fifth example, wherein the updated RACH configuration information is a beam group-based RACH configuration.

[0127] In a thirty ninth example, the method of the thirty eighth example, wherein the updated RACH configuration information is provided in a radio resource control (RRC) message.

[0128] In a fortieth example, the method of the thirty eighth example, wherein the updated RACH configuration information is provided in a system information block (SIB) .

[0129] In a forty first example, the method of the fortieth example, wherein the SIB is a SIB1 with an updated systemInfoValueTag value.

[0130] In a forty second example, the method of the fortieth example, wherein the SIB is a SIB19.

[0131] In a forty third example, the method of the thirty fifth example, further comprising generating, for transmission to the UE, a paging message and generating, for transmission to the UE, a first system information block (SIB) , wherein the updated RACH configuration information is provided in a second SIB.

[0132] In a forty fourth example, the method of the forty third example, wherein the paging message includes systemInfoModification set to true.

[0133] In a forty fifth example, the method of the forty third example, wherein the first SIB includes an updated system information value.

[0134] In a forty sixth example, the method of the forty third example, wherein the second SIB is a SIB19.

[0135] In a forty seventh example, the method of the thirty fifth example, further comprising generating, for transmission to the UE, a paging message, wherein the updated RACH configuration information is provided in a system information block (SIB) .

[0136] In a forty eighth example, the method of the forty seventh example, wherein the paging message includes a short message with a code point configured to indication a RACH configuration modification.

[0137] In a forty ninth example, the method of the forty seventh example, wherein the SIB is a SIB19.

[0138] In a fiftieth example, the method of the thirty fifth example, further comprising generating, for transmission to the UE, downlink configuration information (DCI) , wherein the updated RACH configuration information is provided in a system information block (SIB) .

[0139] In a fifty first example, the method of the fiftieth example, wherein the DCI is group common DCI configured to indicate a RACH configuration update for one or more beams.

[0140] In a fifty second example, the method of the fifty first example, wherein the DCI is DCI format 2_9 comprising an explicit indication of a RACH configuration update.

[0141] In a fifty third example, the method of the fifty second example, wherein the DCI is DCI format 2_9 scrambled with a radio network temporary identifier configured to indicate a RACH configuration update.

[0142] In a fifty fourth example, the method of the fiftieth example, wherein the SIB is a SIB19.

[0143] In a fifty fifth example, the method of the thirty fifth example, wherein the updated RACH configuration information is provided in a system information block 1 (SIB1) .

[0144] In a fifty sixth example, the method of the fifty fifth example, further comprising generating, for transmission to the UE, a paging message causing the UE to receive the SIB1.

[0145] In a fifty seventh example, the method of the fifty sixth example, further comprising generating, for transmission to the UE, a group common downlink control information (DCI) causing the UE to receive the SIB1.

[0146] In a fifty eighth example, the method of the fifty seventh example, wherein the group common DCI is format 2_9.

[0147] In a fifty ninth example, the method of the thirty fifth example, wherein the updated RACH configuration information is provided in a system information block (SIB) and further comprises an activation time for a RACH occasion (RO) update.

[0148] In a sixtieth example, the method of the fifty ninth example, wherein the activation time for the RO update is in a coordinated universal time (UTC) format.

[0149] In a sixty first example, the method of the fifty ninth example, wherein the activation time for the RO update is based on a subframe or a system frame number (SFN) .

[0150] In a sixty second example, the method of the fifty ninth example, wherein the SIB further comprises a validity duration of the RO update.

[0151] In a sixty third example, the method of the thirty fifth example, wherein an activation time for a RACH occasion (RO) update is preconfigured.

[0152] In a sixty fourth example, the method of the sixty third example, wherein a validity time duration for RO update is preconfigured.

[0153] In a sixty fifth example, a processor configured to perform any of the methods of the thirty fifth through sixty fourth examples.

[0154] In a sixty sixth example, a base station comprising a transceiver configured to communicate with a user equipment (UE) and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the thirty fifth through sixty fourth examples.

[0155] Those skilled in the art will understand that the above-described example embodiments may be implemented in any suitable software or hardware configuration or combination thereof. An example hardware platform for implementing the example embodiments may include, for example, an Intel x86 based platform with compatible operating system, a Windows OS, a Mac platform and MAC OS, a mobile device having an operating system such as iOS, Android, etc. The example embodiments of the above described method may be embodied as a program containing lines  of code stored on a non-transitory computer readable storage medium that, when compiled, may be executed on a processor or microprocessor.

[0156] Although this application described various embodiments each having different features in various combinations, those skilled in the art will understand that any of the features of one embodiment may be combined with the features of the other embodiments in any manner not specifically disclaimed or which is not functionally or logically inconsistent with the operation of the device or the stated functions of the disclosed embodiments.

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

[0158] It will be apparent to those skilled in the art that various modifications may be made in the present disclosure, without departing from the spirit or the scope of the disclosure. Thus, it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalent.

Claims

1.An apparatus comprising processing circuitry configured to:process, based on signals received from a base station, random-access channel (RACH) configuration information comprising RACH occasion (RO) configuration information for a non-terrestrial network (NTN) ;process, based on signals received from the base station, updated RACH configuration information comprising updated RO configuration information for the NTN; andperform a RACH procedure using the updated RACH configuration information.2.The apparatus of claim 1, wherein an RO periodicity and offset is configured per synchronization signal block (SSB) .3.The apparatus of claim 2, wherein the updated RACH configuration information is received in a field of a RACH-ConfigCommon information element (IE) .4.The apparatus of claim 2, wherein an RO periodicity is updated based on multiplying a first RO periodicity with a choice value from the field of the RACH-ConfigCommon IE.5.The apparatus of claim 2, wherein an RO offset is updated based on summing a first RO offset value with an integer value from the field of the RACH-ConfigCommon IE times a first RO periodicity.6.The apparatus of claim 1, wherein the updated RACH configuration information comprises a beam group-based RACH configuration.7.The apparatus of claim 6, wherein the updated RACH configuration information is received in a radio resource control (RRC) message.8.The apparatus of claim 6, wherein the updated RACH configuration information is received in a system information block (SIB) .9.The apparatus of claim 8, wherein the SIB is a SIB1 with an updated systemInfoValueTag value.10.The apparatus of claim 8, wherein the SIB is a SIB19.11.The apparatus of claim 1, wherein the processing circuitry processes the updated RACH configuration information based on receiving a paging message and a first system information block (SIB) , wherein the updated RACH configuration information is received in a second SIB.12.The apparatus of claim 11, wherein the paging message includes systemInfoModification set to true.13.The apparatus of claim 11, wherein the first SIB includes an updated system information value.14.The apparatus of claim 11, wherein the second SIB is a SIB19.15.The apparatus of claim 1, wherein the processing circuitry processes the updated RACH configuration information based on  receiving a paging message, wherein the updated RACH configuration information is received in a system information block (SIB) .16.The apparatus of claim 15, wherein the paging message includes a short message with a code point configured to indication a RACH configuration modification.17.The apparatus of claim 15, wherein the SIB is a SIB19.18.The apparatus of claim 1, wherein the processing circuitry processes the updated RACH configuration information based on receiving downlink configuration information (DCI) , wherein the updated RACH configuration information is received in a system information block (SIB) .19.The apparatus of claim 18, wherein the DCI is group common DCI configured to indicate a RACH configuration update for one or more beams.20.The apparatus of claim 19, wherein the DCI is DCI format 2_9 comprising an explicit indication of a RACH configuration update.

Images