Downlink scheduling schemes under beam hopping for non-terrestrial networks

Abstract

An apparatus comprising configured to process, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time and a downlink revisit time, when a scheduled downlink transmission is out of the downlink dwell time for a beam footprint, calculate a time for downlink reception using virtual timing information, wherein virtual timing for the beam footprint is for a time during which there is active beam coverage on the beam footprint and convert the virtual timing information to actual timing information based on the downlink dwell time and the downlink revisit time, wherein the actual timing information is used for the downlink reception.

Description

Downlink Scheduling Schemes Under Beam Hopping for Non-Terrestrial NetworksTechnical Field

[0001] The present disclosure generally relates to wireless communication, and in particular, to downlink scheduling schemes under beam hopping for non-terrestrial networks.Background

[0002] Timing synchronization is important in wireless communication networks. One of the primary differences in non-terrestrial networks (NTNs) compared to terrestrial cellular networks is the significantly longer propagation delay between the user equipment (UE) on the ground and a satellite. Propagation delays may result in signals being received and / or transmitted at very different times, and thereby result in a lack of proper timing between the communication nodes.

[0003] Downlink (DL) coverage enhancements for non-terrestrial networks (NTN) are desired. Various techniques have been discussed relating to downlink coverage enhancements targeting support for additional reference satellite payload parameters covering both geosynchronous orbit (GSO) and non-geosynchronous orbit (NGSO) constellations operating in Frequency Range 1 (FR1) -NTN or Frequency Range 2 (FR2) -NTN. The possible advantages of downlink coverage enhancement include optimized performance especially when addressing handset terminals (including smartphones with -5.5 dB antenna gain) with respect to downlink coverage considering the NTN deployment constraints such as payload power limitation, large satellite footprint and limited feeder link bandwidth. DL coverage enhancements are needed to accommodate satellite payload constraints which may be unable to have all its beams active at  a given time due to limited power and limited feeder link bandwidth. In addition, DL coverage enhancements may help in maximizing the number of beams that may be activated simultaneously, ensuring that all user terminals may be served across the satellite footprint while maximizing the overall satellite throughput, and ensuring that all satellite’s radio cells are kept alive even without traffic but allowing new users to join or preventing impact on end-user QoS.

[0004] In order to achieve these benefits, improved scheduling for downlink transmissions under beam hopping in NTNs is desirable.Summary

[0005] Some example embodiments are related to an apparatus having processing circuitry configured to process, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time and a downlink revisit time, when a scheduled downlink transmission is out of the downlink dwell time for a beam footprint, calculate a time for downlink reception using virtual timing information, wherein virtual timing for the beam footprint is for a time during which there is active beam coverage on the beam footprint and convert the virtual timing information to actual timing information based on the downlink dwell time and the downlink revisit time, wherein the actual timing information is used for the downlink reception.

[0006] Other example embodiments are related to an apparatus having processing circuitry configured to process, based on signals received from a network, beam-based configuration  information, wherein the beam-based configuration information comprises a downlink dwell time, a downlink revisit time, a downlink starting dwell time, and a time period for a first Random Access Response (RAR) window, generate, for transmission to the network, a physical random access channel (PRACH) request at a time slot n within an uplink dwell time according to the downlink starting dwell time, estimate a round trip time (RTT) for the PRACH request and monitor for a Random Access Response (RAR) during a second RAR window that is based on the RTT and the downlink dwell time.

[0007] Still further example embodiments are related to an apparatus having processing circuitry configured to process, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time, a downlink revisit time, and a downlink starting dwell time, determine a starting time of RAR window monitoring, based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time and determine a downlink reception timing based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time.Brief Description of the Drawings

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

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

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

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

[0012] Fig. 5A shows an example beam based NTN configuration according to various example embodiments.

[0013] Fig. 5B shows an example timing diagram for actual downlink timing for a UE according to various example embodiments.

[0014] Fig. 5C shows an example timing diagram for virtual downlink timing for a UE according to various example embodiments.

[0015] Figs. 6A and 6B show example timing diagrams for downlink scheduling for periodic DL transmissions according to various example embodiments.

[0016] Figs. 7A and 7B show example timing diagrams for downlink scheduling for multiple-slot DL transmissions according to various example embodiments.

[0017] Fig. 8 shows an example Random Access Response Window according to various example embodiments.

[0018] Figs. 9A-9C show example timing diagrams for downlink scheduling utilizing an extended Random Access Response (RAR) window according to various example embodiments.

[0019] Fig. 10 shows an example flow diagram illustrating an example procedure for performing downlink scheduling under beam hopping in an NTN according to various example embodiments.Detailed Description

[0020] 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 enhanced downlink coverage, particularly in NTN at both the link level and the system level. In particular, it is proposed to provide downlink (DL) scheduling schemes under beam hopping for NTNs.

[0021] The example embodiments are described with regard to a 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 an accessory device and is configured with the hardware, software, and / or firmware to exchange information and data with accessory devices. Therefore, the UE as described herein is used to represent any electronic component.

[0022] The example embodiments are also described with reference to a 5G New Radio (NR) network. However, the example embodiments may also be implemented in other types of networks, including but not limited to LTE networks, future evolutions of the cellular protocol (e.g., 5G-advanced networks, 6G networks, etc. ) , or any other type of network.

[0023] The example embodiments are also described with reference to carrier aggregation (CA) . In CA, a UE may communicate in the downlink (DL) or uplink (UL) with multiple cells of a network to increase throughput. CA includes the UE associating with a Primary Cell (PCell) and one or more Secondary Cells (SCells) . Different band combinations of CA may be served by the PCell and SCell, e.g., the PCell may serve a first component carrier (CC) of a CA band combination (e.g.,  CC1) to the UE and the SCell may serve a second CC of the CA band combination (e.g., CC2) to the UE. Thus, in CA, both the PCell and the SCell are considered to be serving cells. CA mode may include multiple SCells. In the example embodiments, it may be considered that the PCell and SCell (s) are co-located, e.g., in the same general physical location (e.g., on the same cell tower) . The PCell and the SCells may be cells of different gNBs or a single gNB. In the present embodiments, the PCell may be the anchor cell and the SCell (s) may be the eNES cell (s) .

[0024] The example embodiments are also described with reference to system information (SI) , in particular system information block 1 (SIB1) , and the physical random access channel (PRACH) . SIB1 may be broadcast by a cell for reception by a UE and may include parameters that are critical for operations including, e.g., initial access. Based on the parameters decoded from SIB1, the UE may transmit a RACH preamble on PRACH to attempt to access the cell. The UE may continue to monitor for SIB1 even after entering the connected state with the cell, e.g., to detect changes to SIB1 parameters such as, e.g., scheduling information, to adapt to changing network conditions. The PRACH configuration carried in SIB1 may also change after connection establishment. Although PRACH is typically transmitted as Msg1 of initial access, the PRACH may be used in other scenarios, e.g., handover or RACH after initial connection establishment. Accordingly, SIB1 may be transmitted periodically by the cell and decoded periodically by the UE even after entering the connected state. Some SIB1 transmissions may include a full set of SIB1 parameters while other SIB1 transmissions may include a subset of SIB1 parameters, e.g., those parameters that have changed since the last SIB1 transmission.

[0025] The example embodiments provide operations for a UE to receive DL scheduling configuration parameters and to implement enhanced DL scheduling under beam hopping for NTNs. Each of these example embodiments will be described in greater detail below.

[0026] 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, embedded devices, wearables, Internet of Things (IoT) devices, etc. An actual network arrangement may include any number of UEs being used by any number of users. Thus, the example of one UE 110 is merely provided for illustrative purposes.

[0027] 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 legacy cellular network, 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.

[0028] The 5G NR RAN 120 may be portions of a cellular network that may be deployed by a network carrier (e.g.,  Verizon, AT&T, T-Mobile, etc. ) . The RAN 120 may include cells or base stations that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set. In this example, the 5G NR RAN 120 includes the gNB 120A and the gNB 120B. However, reference to a gNB is merely provided for illustrative purposes, any appropriate base station or cell may be deployed (e.g., Node Bs, eNodeBs, HeNBs, eNBs, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc. ) .

[0029] 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 network carrier 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., gNB 120A) .

[0030] In this example, it may be considered that the UE 110 is operating in CA mode where the gNB 120A is the PCell and the gNB 120B is the SCell that will be operating in enhanced network energy saving (eNES) mode (s) . As described above, CA mode may include multiple SCells but for the purpose of description only a single SCell is shown. In the example embodiments, it may be considered that the PCell and SCell are co-located, e.g., in the same general physical location (e.g., on the same cell tower) . Also, while the PCell and SCell are shown as being different gNBs, a single gNB may include multiple cells. Thus, the PCell and SCell may be cells of the same gNB.

[0031] 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 manages the traffic that flows between the cellular network and the Internet 140. 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.

[0032] 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 represent any electronic device and 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 battery that provides a limited power supply, a data acquisition device, ports to electrically connect the UE 110 to other electronic devices, sensors to detect conditions of the UE 110, etc.

[0033] The processor 205 may be configured to execute a plurality of engines for the UE 110. For example, the engines may include a scheduling engine 235 for performing operations  related to enhancing downlink coverage by supporting DL scheduling under beam hopping for NTNs. The scheduling engine 235 may also support the UE performing additional operations in DL scheduling, such as DL scheduling based on virtual timing slots, extending a Random Access (RA) Response Window, and receiving signaling that includes configuration information for DL scheduling. The scheduling engine 235 may also perform operations related to receiving SIB1 and / or PRACH related information, receiving configuration information and / or activation signaling for applying a configuration for a given beam and performing operations on the beam in dependence on this information / signaling. Each of these example operations will be described in more detail below. The engines may also include a positioning engine 240 for transmitting positioning signals to each of a plurality of positioning nodes based on a network configuration for the positioning signals. The positioning signals are estimated by the positioning nodes to provide the network with information so that the network may determine a location of the UE, to be described in further detail below.

[0034] The above referenced engines 235 and 240 being applications (e.g., programs) executed by the processor 205 is only example. The functionality associated with the engines 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 engines 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.

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

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

[0037] Fig. 3 shows an example base station 300 according to various example embodiments. The base station 300 may represent the gNB 120A, the gNB 120B or any other access node through which the UE 110 may establish a connection and manage network  operations. It may be considered that the base station 300 is an anchor cell according to the present embodiments.

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

[0039] The processor 305 may be configured to execute a plurality of engines for the UE 110. For example, when the gNB 120A is a serving cell for a UE, the engines may include a UE configuration engine 335 for providing UE configuration information to the network, for example, information relating to periods when the UE is in a DRX inactive mode or has a measurement gap (MG) . The network may then distribute the information to positioning nodes so that the positioning nodes may monitor. The engines may also include a scheduling engine 340 for performing operations related to beam-based configuration and / or signaling, including for DL scheduling under beam hopping. The scheduling engine 340 may also provide information to the UE to support the UE performing additional operations in DL scheduling under beam hopping for NTNs. The scheduling engine 340 may also perform operations related to transmitting configuration information and / or activation signaling for applying a configuration for a given beam and performing operations on the beam in dependence on this information / signaling. The scheduling engine 340 may also be used for receiving the UE configuration information from the network and monitoring for positioning signals from the UE in  accordance therewith. For example, the gNB 120A may determine a period during which it will monitor for the positioning signals and a period during which it will not monitor for the positioning signals based on the UE configuration information, to be described in further detail below, and estimate the positioning signals when it is received from the UE. Each of these example operations will be described in more detail below.

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

[0041] The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UE in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . 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.

[0042] Fig. 4 shows an example non-terrestrial network (NTN) architecture 4 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 UEs in the coverage area of the NTN.

[0043] The NTN architecture 400 represents a network arrangement including one or more satellites, which in this example shows a single satellite 410 that is 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 terrestrial network 440 with the NTN components. In the NTN architecture 400 of Fig. 4, the gateway 430 and the satellite 410 may communicate via feeder links. In some NTN deployments, satellites may be served by several gateways simultaneously.

[0044] The satellite provides network services to a UE 110 via a service link. The satellite 410 may implement either a transparent payload or a regenerative payload. A transparent payload refers to an arrangement where the satellite 1110 may receive a signal 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 satellite 410 acts 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.

[0045] With reference to Fig. 1, in a regenerative payload arrangement, the gNB 120A may be located on an aerial component, e.g., the satellite 410 of Fig. 4. In a transparent payload arrangement, the gNB 120A may be located on the ground and the satellite 410 is used to mirror the signals between the gNB 120A and the UE 110, as described above.

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

[0047] As described above, the example embodiments are related to enhanced DL scheduling schemes for beam hopping in NTNs.

[0048] Downlink (DL) coverage enhancements for non-terrestrial networks (NTN) are desired. Various techniques have been discussed in standards bodies. For example, in Rel-19, discussions and study have been had relating to downlink coverage enhancements targeting support for additional reference satellite payload parameters covering both geosynchronous orbit (GSO) and non-geosynchronous orbit (NGSO) constellations operating in Frequency Range 1 (FR1) -NTN or Frequency Range 2  (FR2) -NTN [RAN1, RAN2, RAN4] . Other discussions include additional reference satellite payload parameters assuming power sharing among satellite beams or different satellite beam patterns / size (i.e. wide or narrow) across the satellite footprint, such that satellite beams may not all be simultaneously active or may be active below the nominal Effective Isotropic Radiated Power (EIRP) density per satellite beam (see section 6.1.1 in TR 38.821) due to limited power and limited feeder link bandwidth. Also studied have been solutions, including link level enhancements for FR1-NTN (e.g. for Physical Downlink Control Channel (PDCCH) and Physical Downlink Shared Channel (PDSCH) ) and / or system level enhancements for FR1-NTN and / or FR2-NTN, allowing dynamic and flexible power sharing between satellite beams or different satellite beam patterns / size (i.e. wide or narrow) across the satellite footprint.

[0049] Synchronization Signal Block (SSB) channel enhancement other than SSB periodicity extension is not considered. Issues such as UE’s cell search complexity and impact to initial cell selection, latency and success rate, for the above extension should be considered. Rel-18 network energy saving techniques should be considered as a baseline.

[0050] The possible advantages of downlink coverage enhancement include optimized performance especially when addressing handset terminals (including smartphones with -5.5 dB antenna gain) with respect to downlink coverage considering the NTN deployment constraints such as payload power limitation, large satellite footprint and limited feeder link bandwidth. Satellite based networks have coverage areas as large as two million square kilometers with coverage areas on the ground  (footprints) as small as fifty kilometers. DL coverage enhancements are needed to accommodate satellite payload constraints which may be unable to have all its beams active with the nominal EIRP density per beam (see Section 6.1.1 in TR 38.821) at a given time due to limited power and limited feeder link bandwidth. In addition, DL coverage enhancements may help in maximizing the number of beams that may be activated simultaneously, ensuring that all user terminals may be served across the satellite footprint while maximizing the overall satellite throughput, and ensuring that all satellite’s radio cells are kept alive even without traffic but allowing new users to join or preventing impact on end-user QoS.

[0051] DL coverage enhancements may be considered at both the link level and the system level. At the link level, they may improve the link margin of selected physical channels in order to accommodate the EIRP reduction in FR1-NTN. A link margin improvement for physical channels (e.g. PDSCH and PDCCH) may be considered without impact on SSB design. System level enhancements may support an efficient dynamic and flexible power sharing between beams or different beam pattern / size (i.e., wide or narrow) across the satellite footprint for FR1-NTN and FR2-NTN.

[0052] Results of DL coverage ratio evaluation at system level have been collected from seven sources for all the three LEO600km satellite parameter sets where the beam footprint diameter is 50 km. For Set 1-1 / 1-3, the coverage ratio may be improved from 10%to 100%if the SSB periodicity is increased from 20ms to 80ms and beam hopping is applied. For Set 1-2, the coverage ratio may be improved from 1.5%to 96.8%if the SSB periodicity is increased from 20ms to 320ms and beam hopping is  applied. Note that coverage ratio is N2+N3 / total beam footprints and the baseline assumes no beam hopping.

[0053] Results of DL coverage ratio evaluation at system level have been collected from three sources for a deployment scenario implementing wide beam footprint. One source reports that with a deployment of wide beam covering four narrow (50km size) beams, which means Set 1-2 FR1 with additional EIRP reduction of 6dB, using SSB periodicity of 80 ms may provide coverage ratio of 96.8%, and Set 1-1 / 1-3 FR1 with additional EIRP reduction of 6dB, SSB periodicity of 80 ms may provide coverage of 100%. Another source observed that for Set 1-1, 1-2 and 1-3, the coverage ratio may be improved from 1.5%to 100%using the legacy default SSB periodicity of 20ms during initial access, by choosing a wide beam footprint with beam footprint sizes of 84 km and 56 km respectively. Note that the PDCCH and the PDSCH for SIB19 is assumed to be transmitted within two orthogonal frequency-division multiplexing (OFDM) symbols and five Megahertz (MHz) bandwidth. The PDSCH for SIB1 is assumed to be transmitted within three OFDM symbols and five MHz bandwidth. This assumes no SIB1 and SIB19 transmission in N2 beam footprints. This assumes non-aligned SFN timing across different beams. Another source observed, for Set 1-1 with increased beam size, that the legacy SSB periodicity of 20ms during initial access is usable with NTN beam hopping, by choosing a deployment scenario implementing wide beam footprint with beam footprint sizes of 70.7 km and 86.6 km, leading to a total of 529 and 353 beam footprints within the satellite coverage area, respectively, and the coverage ratio is 80%and 90%, respectively, and a ratio of simultaneously active beam footprints to the total number of beam foot prints equal to 20% and 30%. Beam footprint size is increased by increasing only the adjacent beam spacing without increasing the 3dB beamwidth.

[0054] In order to achieve these benefits, a scheduling scheme for downlink transmissions under beam hopping in NTNs is hereby proposed. The concept of virtual timing under beam hopping is introduced. DL scheduling may be based on virtual timing, as discussed further below. A UE may then switch from virtual timing to actual timing. Also proposed are schemes to address DL scheduling for periodic transmissions and DL scheduling for multiple-slot transmissions. An RA response window monitoring time will also be discussed. Signaling for downlink scheduling under beam hopping and an example procedure of downlink scheduling under beam hopping will also be disclosed.

[0055] In a typical downlink transmission, a UE will first receive a downlink control information (DCI) transmission, which tells the UE that data is coming at a certain time. However, in NTN scenarios, the time for the data transmission may be during a non-active beam footprint, as seen in Fig. 5A. Fig. 5A shows an example beam based NTN configuration according to various example embodiments. The example beam based NTN configuration 500 may include a satellite 510 that provides a large area of coverage with multiple beam footprints 520, 530, and 540, with each beam footprint covering a smaller area. Although Fig. 5A shows three beam footprints, this is an example only, and the number of beam footprints may vary. In a first time period (time unit #1) , beam footprint 520 is the active beam footprint, while beam footprints 530 and 540 are non-active. In time period #2, the active beam footprint is beam footprint 530 and beam footprints 520 and 540 are non-active beam footprints. In time  period #3, the active beam footprint is beam footprint 540 and beams 520 and 530 are non-active beam footprints. Beam footprint 520 does not become the active footprint again until time unit #4 in this example. Thus, if a DCI transmission is received in time unit #1 for beam footprint 520, the scheduled DL transmission time may be in the non-active time for beam footprint 520.

[0056] To address this issue, a virtual timing scheme is introduced for DL scheduling. Fig. 5B shows an example timing diagram for actual DL timing for the UE according to various example embodiments. Fig. 5C shows an example timing diagram for virtual DL timing for the UE according to various example embodiments. The virtual timing scheme may utilize a dwell time and a revisit time. The dwell time is the time that the network is using the beam to cover the area (i.e., the beam footprint is an active beam footprint) . The revisit time is the amount of wait time until the particular beam footprint is active again. In an NTN, the data may be received at a much later time (way after the DCI is received) .

[0057] As one example, as seen in Figs. 5B and 5C, the DL transmission may be a PDSCH transmission. However, the virtual timing scheme applies to any other DL transmission.

[0058] As mentioned, the scheduled downlink transmissions (e.g., PDSCH) time may be out of the dwell time of the beam footprint, as seen in Fig. 5B. Fig. 5B shows the UE actual DL timing, which includes a dwell time D and a revisit time R. Fig. 5C shows the UE virtual DL timing. Looking at Fig. 5B, the UE may receive the DCI transmission in the dwell time D. There may be a remaining amount of time A left in the dwell time after  the DCI transmission is received. There is then a period of time (the revisit time) until the UE is in an active beam footprint and may receive the PDSCH data at a time of K0-A.

[0059] Referring to Fig. 5C, for purposes of the virtual timing, the PDSCH data may be considered as received at a time K0 after the dwell time. Virtual timing for a beam footprint is the time in which there is beam coverage on the beam footprint. In a first step, the scheduled downlink transmissions may be calculated over virtual timing. In a second step, the virtual timing could be converted to actual timing, based on the configured dwell time (D) and revisit time (R) , For example, suppose the scheduling DL DCI is at slot n, and the time gap between PDCCH and PDSCH is K0. Also suppose the remaining time of the current dwell time from slot n is A, as seen in Fig. 5B. If K0 <= A (i.e., PDSCH is in the same dwell time as PDCCH) , then the PDSCH is at the actual timing slot n+ K0. If K0 > A (i.e., PDSCH is in the following dwell time as PDCCH) , then the PDSCH is at actual time slot

[0060] For example, if the dwell time D is 20 ms (or 20 slots under 15 kHz SCS) , and the revisit time R=80 ms (or 80 slots under 15 kHz SCS) , and K0 = 14 slots, and A = 3 slots, then the PDSCH actual timing is slot n+3+60+11, or n+74.

[0061] In one embodiment, the dwell time D and the revisit time R may be configured by a network for all UEs associated with a beam and provided to the UE (s) in network configuration information. In one embodiment, this may be accomplished via a SIB transmission.

[0062] By using the virtual timing scheme, the K0 does not have to be changed. In the example of Figs. 5B and 5C, the second and third time units may be excluded and only the timing that the particular beam footprint is being served is considered.

[0063] Also proposed is a DL scheduling scheme for periodic DL transmissions. Figs. 6A and 6B are example timing diagrams showing DL scheduling for periodic DL transmissions according to various example embodiments. The DL scheduling for periodic DL transmissions may include the virtual timing scheme described above in some embodiments. In one embodiment, as seen in Figs. 6A and 6B, the periodic DL transmission may be semi-persistent (SPS) PDSCH, but the technique applies to PDCCH or any other periodic downlink transmissions. In a first embodiment, the SPS PDSCH timing is determined via UE virtual DL timing using the same technique as discussed with respect to Fig. 5 above. In another embodiment, the SPS PDSCH timing may be determined via the UE actual DL timing. If a SPS PDSCH is not in the actual DL timing, then there are two alternatives. In the first alternative, the SPS PDSCH is simply skipped, as seen in Fig. 6A. In a second alternative, as seen in Fig. 6B, this SPS PDSCH is delayed to the beginning of the following DL dwell time. In still another embodiment, the SPS PDSCH periodicity may be modified according to the UE actual DL timing. As one example, the new SPS PDSCH periodicity may be the least common multiple of the old SPS PDSCH periodicity and the revisit time. In yet another embodiment, the SPS PDSCH periodicity may be configured and is in the following range: periodicity = k* {R, R+D} , where R is the revisit time, D is the dwell time, and k=1, 2, …

[0064] Also proposed is a DL scheduling scheme for multiple slot DL transmissions. Figs. 7A and 7B are example timing diagrams showing DL scheduling for multiple slot DL transmissions according to various example embodiments. The DL scheduling for multiple slot DL transmissions may include the virtual timing scheme described above in some embodiments. In one embodiment, as seen in Figs. 7A and 7B, the multiple slot DL transmission may be PDSCH repetition, but the technique applies to any other multiple slot downlink transmissions. In a first embodiment, the PDSCH repetition timing is determined via UE virtual DL timing, as discussed above with respect to Fig. 5. In another embodiment, the PDSCH repetition timing is determined via the UE actual DL timing. If a PDSCH repetition is not in the actual DL timing, there are two alternatives. In the first alternative, the PDSCH repetition that is not in the actual DL timing is skipped, as seen in Fig. 7A. In the second alternative, this PDSCH repetition is delayed to the beginning of the following DL dwell time, as seen in Fig. 7B.

[0065] Another proposal to enhance DL scheduling for beam hopping for NTNs involves extension of the random access (RA) response (RAR) window. This extension of the RAR window may apply to both 4-step RACH and 2-step RACH (ra-ResponseWindow (RAR window) and msgB-ResponseWindow (MsgB window) ) . In licensed spectrum, the window size is 10 ms. For simplicity, the assumption is that the RAR window = 10 ms.

[0066] Fig. 8 shows an example Random Access Response Window according to various example embodiments. In a typical system, a PRACH is sent. An estimate of the time for starting a window for the RAR is made (i.e., an estimate of the Round Trip Time  (RTT) between the UE and a gNB. The monitoring window may be 10 ms. However, in an NTN, the UE-gNB RTT may be extremely long.

[0067] In beam hopping for NTN, an extension of the RAR window may provide enhanced DL scheduling. Figs. 9A-9C show example timing diagrams for DL scheduling utilizing an extended Random Access Response (RAR) window according to various example embodiments. Looking at Fig. 9A, suppose a PRACH is sent at absolute time n, which is in the UL Dwell time according to a network indicated starting Dwell time. The UL Dwell time D is a timing advance (TA) ahead of the DL timing (i.e., the DL Dwell time) . An estimate of the RTT between the UE and the gNB is made. If the estimated time (n+RTT) falls within the DL dwell time, any remaining DL dwell time may be referred to as B. If the remaining DL Dwell time is greater than or equal to the RAR window (i.e., B >= RAR window) , then the UE may monitor RAR from absolute time (n+RTT) until (n+RTT+RAR window) , i.e. to the end of the RAR window, as seen in Fig. 9A.

[0068] If the remaining DL Dwell time is less than the RAR window (B< RAR window) , then the UE may monitor RAR from absolute time (n+RTT) until the end of the DL dwell time. In a first alternative, the UE may continue to monitor RAR from the beginning of the next DL dwell time until the total RAR monitoring duration reaches that of the RAR window, as seen in Fig. 9B. In a second alternative, the UE does not continue to monitor RAR at the next DL dwell time.

[0069] On the other hand, if (n+RTT) is out of the DL dwell time, then the UE may start to monitor RAR from the beginning of the next DL dwell time until the total RAR monitoring duration reaches that of the RAR window, as seen in Fig 9C. In another  embodiment, the UE may retransmit the PRACH preamble in a valid RACH occasion (RO) for another RACH attempt.

[0070] Signaling for DL scheduling under beam hopping in NTNs are also proposed. The container for the signaling may include SID 1, SIB19, or a new SIB. The contents of the container may include a downlink dwell time (D) and a downlink revisit time (R) . In a first embodiment, the downlink dwell time (D) and a downlink revisit time (R) may be configured per cell. The revisit time (R) may be implicitly derived from the dwell time and the total number of SSB indexes in a cell (B) , e.g., R = B*D. For the legacy case of terrestrial networks, D= infinity and R= infinity.

[0071] In a second embodiment, the downlink dwell time (D) and a downlink revisit time (R) may be configured per beam or beam footprint (associated with SSB index) . The dwell time (D) and the revisit time (R) could be non-uniformly distributed over different SSB indexes.

[0072] The downlink starting dwell time is sent per beam footprint (maybe in terms of SSB index) . In the case where D and R are configured per cell, and supposing cell specific downlink dwell time (D) and downlink revisit time (R) are configured, a SSB #0 starting downlink dwell time may be configured as SFN = A. The SSB #X starting downlink dwell time may be determined by SFN=X*D+A + k*R, where X =0, 1, 2, …and k=1, 2, …

[0073] In the case where D and R are configured per beam, beam specific downlink dwell time (Di) and downlink revisit time (Ri) may be configured for each SSB index i. The SSB index i specific starting downlink dwell time may be configured as SFN =  Ai. The SSB index i starting downlink dwell time may be determined by SFN = Ai+k*Ri, where k=1, 2, ….

[0074] In a procedure of downlink scheduling under beam hopping in an NTN, the following steps may be performed. Fig. 10 shows an example flow diagram illustrating an example procedure for performing DL scheduling under beam hopping in an NTN according to various example embodiments. In the example procedure 1000, the UE may receive configuration information from a network (e.g., from a gNB) that includes a downlink dwell time, a downlink revisit time and a downlink starting dwell time (1010) . This may occur using the signaling described above, such as via SIB, and may be configured per cell or per beam as previously discussed. The UE may determine a starting time of RAR window monitoring, based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time, associated with the SSB beam (1020) . This may be accomplished using an extension of the RAR window, as disclosed above with respect to Figs. 9A-9C. The UE may also determine a DL reception timing based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time, associated with the SSB beam (1030) . This may be done using the virtual timing schemes proposed herein.

[0075] The above example techniques may be used together, used independently from one another, in conjunction with other currently implemented mechanisms for DL scheduling in NTNs, in conjunction with future implementations of DL scheduling schemes in NTNs, and independently from other mechanisms for DL scheduling in NTNs.

[0076] By using the proposed DL scheduling schemes under beam hopping for NTNs, improved downlink coverage may be enhanced in NTNs on both a link level and a system level.

[0077] Examples

[0078] In a first example, a method comprising processing, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time and a downlink revisit time, when a scheduled downlink transmission is out of the downlink dwell time for a beam footprint, calculate a time for downlink reception using virtual timing information, wherein virtual timing for the beam footprint is for a time during which there is active beam coverage on the beam footprint and convert the virtual timing information to actual timing information based on the downlink dwell time and the downlink revisit time, wherein the actual timing information is used for the downlink reception.

[0079] In a second example, the method of the first example, wherein the scheduled downlink transmission is a Physical Downlink Shared Channel (PDSCH) transmission.

[0080] In a third example, the method of the second example, further comprising receiving scheduling downlink control information (DCI) at a time slot n, wherein a time gap between a Physical Downlink Control Channel (PDCCH) transmission and the PDSCH transmission is K0, and wherein a remaining amount of time in the current downlink dwell time from slot n is A, the actual timing information comprises an actual timing slot of n+K0 where K0 is less than or equal to A.

[0081] In a fourth example, the method of the second example, further comprising receiving scheduling downlink control information (DCI) at a time slot n, wherein a time gap between a Physical Downlink Control Channel (PDCCH) transmission and the PDSCH transmission is K0, and wherein a remaining amount of time in the current downlink dwell time from slot n is A, the actual timing information comprises an actual timing slot of

[0082] where K0 is greater than A.

[0083] In a fifth example, the method of the first example, further comprising receiving a downlink transmission using the actual timing information.

[0084] In a sixth example, the method of the first example, wherein the scheduled downlink transmission is a periodic downlink transmission.

[0085] In a seventh example, the method of the sixth example, wherein if the periodic downlink transmission is not in an actual timing slot of the actual timing information, the processing circuitry is configured to skip the periodic transmission.

[0086] In an eighth example, the method of the sixth example, wherein if the periodic downlink transmission is not in an actual timing slot of the actual timing information, the method further comprises delaying the periodic transmission to a beginning of a following downlink dwell time.

[0087] In a ninth example, the method of the sixth example, further comprising modifying a periodicity of the periodic downlink transmission based on the actual timing information.

[0088] In a tenth example, the method of the ninth example, wherein a modified periodicity is a least common multiple of the periodicity and the revisit time.

[0089] In an eleventh seventh example, the method of the first example, wherein the scheduled downlink transmission is a multi-slot downlink transmission.

[0090] In a twelfth example, the method of the eleventh example, wherein if the multi-slot downlink transmission is not in an actual timing slot of the actual timing information, the method further comprising skipping the multi-slot downlink transmission.

[0091] In a thirteenth example, the method of the eleventh example, wherein if the multi-slot downlink transmission is not in an actual timing slot of the actual timing information, the method further comprises delaying the multi-slot downlink transmission to a beginning of a following downlink dwell time.

[0092] In a fourteenth example, the method of the first example, wherein the beam-based configuration information is received from the network in a system information block (SIB) message, wherein the SIB message comprises one or more of SIB1 and SIB 19.

[0093] In a fifteenth example, the method of the first example, wherein the downlink dwell time and the downlink revisit time are configured per cell.

[0094] In a sixteenth example, the method of the fifteenth example, wherein the downlink revisit time is implicitly derived from the downlink dwell time and a total number of synchronization signal block (SSB) indexes in a cell.

[0095] In a seventeenth example, the method of the fifteenth example, wherein a first starting downlink dwell time SSB #0 is configured as SFN=A and a second starting downlink dwell time SSB #X is determined by SFN=X*D+A + k*R, where X =0, 1, 2, …and k=1, 2, …

[0096] In an eighteenth example, the method of the first example, wherein the downlink dwell time and the downlink revisit time are configured per beam or beam footprint.

[0097] In a nineteenth example, the method of the eighteenth example, wherein the downlink dwell time and the downlink revisit time are non-uniformly distributed over different synchronization signal block (SSB) indexes.

[0098] In a twentieth example, the method of the eighteenth example, wherein a beam specific downlink dwell time (Di) and a beam specific downlink revisit time (Ri) are configured for each SSB index i, a SSB index i specific starting downlink dwell time is configured as SFN = Ai, and a SSB index i starting downlink dwell time is determined by SFN = Ai+k*Ri, where k=1, 2, ….

[0099] In a twenty first example, the method of the first example, wherein the apparatus is part of a non-terrestrial network (NTN) .

[0100] In a twenty second example, a processor configured to perform any of the methods of the first through twenty first examples.

[0101] In a twenty third example, a user equipment (UE) configured to perform any of the methods of the first through twenty first examples.

[0102] In a twenty fourth example, a method, comprising processing, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time, a downlink revisit time, a downlink starting dwell time, and a time period for a first Random Access Response (RAR) window, generate a physical random access channel (PRACH) request at a time slot n within an uplink dwell time according to the downlink starting dwell time, estimate a round trip time (RTT) for the PRACH request and monitor for a Random Access Response (RAR) during a second RAR window that is based on the RTT and the downlink dwell time.

[0103] In a twenty fifth example, the method of the twenty fourth example, wherein, if a time slot of n+RTT is within the downlink dwell time, and a remining amount of time in the downlink dwell time is equal to or greater than the time period for the first RAR window, the method further comprising monitoring for the RAR during the second RAR window, wherein the second RAR window is from the time slot of n+RTT until a time slot of n+RTT+the time period of the first RAR window.

[0104] In a twenty sixth example, the method of the twenty fourth example, wherein, if a time slot of n+RTT is within the downlink dwell time, and a remining amount of time in the downlink dwell time is less than the time period for the first RAR window, the method further comprising monitoring for the RAR during the second RAR window, wherein the second RAR window is from the time slot of n+RTT until an end of the downlink dwell time.

[0105] In a twenty seventh example, the method of the twenty sixth example, further comprising continuing to monitor for RAR from a beginning of a next downlink dwell time until a total RAR monitoring duration reaches that of the first RAR window.

[0106] In a twenty eighth example, the method of the twenty sixth example, further comprising discontinuing to monitor for RAR at a beginning of a next downlink dwell time.

[0107] In a twenty ninth example, the method of the twenty fourth example, wherein, if a time slot of n+RTT is not within the downlink dwell time, the method further comprises monitoring for RAR from a beginning of a next downlink dwell time until a total RAR monitoring duration reaches that of the first RAR window.

[0108] In a thirtieth example, the method of the twenty fourth example, wherein if a time slot of n+RTT is not within the downlink dwell time, the method further comprises re-transmitting a PRACH preamble in a valid RACH occasion for another RACH attempt.

[0109] In a thirty first example, the method of the twenty fourth example, wherein the time period for the first RAR window is ten milliseconds (10 ms) .

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

[0111] In a thirty third example, a user equipment (UE) configured to perform any of the methods of the twenty fourth through thirty first examples.

[0112] In a thirty fourth example, a method comprising processing, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time, a downlink revisit time, and a downlink starting dwell time, determining a starting time of RAR window monitoring, based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time and determining a downlink reception timing based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time.

[0113] In a thirty fifth example, the method of the thirty fourth example, wherein the beam-based configuration information is received from the network in a system information block (SIB) message, wherein the SIB message comprises one or more of SIB1 and SIB 19.

[0114] In a thirty sixth example, the method of the thirty fourth example, wherein the downlink dwell time and the downlink revisit time are configured per cell.

[0115] In a thirty seventh example, the method of the thirty fourth example, wherein the downlink dwell time and the downlink revisit time are configured per beam or beam footprint.

[0116] In a thirty eigth example, the method of the thirty fourth example, wherein determining the downlink reception timing is based on calculating a time for the downlink reception using virtual timing information, wherein virtual timing for the beam footprint is for a time during which there is active beam coverage on the beam footprint and converting the virtual timing information to actual timing information based on the downlink dwell time and the downlink revisit time, wherein the actual timing information is used for the downlink reception.

[0117] In a thirty ninth example, the method of the thirty fourth example, wherein determining the starting time of RAR window monitoring is based on transmitting a physical random access channel (PRACH) request at a time slot n within an uplink dwell time according to the downlink starting dwell time, estimating a round trip time (RTT) for the PRACH request and monitoring for RAR during an RAR window that is based on the RTT and the downlink dwell time.

[0118] In a fortieth example, a processor configured to perform any of the methods of the thirty fourth through thirty ninth examples.

[0119] In a forty first example, a user equipment (UE) configured to perform any of the methods of the thirty fourth through thirty ninth examples.

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

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

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

[0123] 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 network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time and a downlink revisit time;when a scheduled downlink transmission is out of the downlink dwell time for a beam footprint, calculate a time for downlink reception using virtual timing information, wherein virtual timing for the beam footprint is for a time during which there is active beam coverage on the beam footprint; andconvert the virtual timing information to actual timing information based on the downlink dwell time and the downlink revisit time, wherein the actual timing information is used for the downlink reception.2.The apparatus of claim 1, wherein the scheduled downlink transmission is a Physical Downlink Shared Channel (PDSCH) transmission.3.The apparatus of claim 2, wherein the processing circuitry is configured to receive scheduling downlink control information (DCI) at a time slot n, wherein a time gap between a Physical Downlink Control Channel (PDCCH) transmission and the PDSCH transmission is K0, and wherein a remaining amount of time in the current downlink dwell time from slot n is A, the actual timing information comprises an actual timing slot of n+K0 where K0 is less than or equal to A.4.The apparatus of claim 2, wherein the processing circuitry is configured to receive scheduling downlink control information (DCI) at a time slot n, wherein a time gap between a Physical  Downlink Control Channel (PDCCH) transmission and the PDSCH transmission is K0, and wherein a remaining amount of time in the current downlink dwell time from slot n is A, the actual timing information comprises an actual timing slot of where K0 is greater than A.5.The apparatus of claim 1, wherein the scheduled downlink transmission is a periodic downlink transmission.6.The apparatus of claim 5, wherein, when the periodic downlink transmission is not in an actual timing slot of the actual timing information, the processing circuitry is configured to skip the periodic transmission.7.The apparatus of claim 5, wherein, when the periodic downlink transmission is not in an actual timing slot of the actual timing information, the processing circuitry is configured to delay the periodic transmission to a beginning of a following downlink dwell time.8.The apparatus of claim 1, wherein the scheduled downlink transmission is a multi-slot downlink transmission.9.The apparatus of claim 8, wherein, when the multi-slot downlink transmission is not in an actual timing slot of the actual timing information, the processing circuitry is configured to skip the multi-slot downlink transmission.10.The apparatus of claim 8, wherein, when the multi-slot downlink transmission is not in an actual timing slot of the actual timing information, the processing circuitry is configured to delay the multi-slot downlink transmission to a beginning of a following downlink dwell time.11.The apparatus of claim 1, wherein the beam-based configuration information is received from the network in a system information block (SIB) message, wherein the SIB message comprises one or more of SIB1 and SIB 19.12.The apparatus of claim 1, wherein the downlink dwell time and the downlink revisit time are configured per cell.13.The apparatus of claim 12, wherein the downlink revisit time is implicitly derived from the downlink dwell time and a total number of synchronization signal block (SSB) indexes in a cell.14.The apparatus of claim 12, wherein a first starting downlink dwell time SSB #0 is configured as SFN=A and a second starting downlink dwell time SSB #X is determined by SFN=X*D+A +k*R, where X =0, 1, 2, …and k=1, 2, …15.The apparatus of claim 1, wherein the downlink dwell time and the downlink revisit time are configured per beam or beam footprint.16.The apparatus of claim 15, wherein the downlink dwell time and the downlink revisit time are non-uniformly distributed over different synchronization signal block (SSB) indexes.17.The apparatus of claim 15, wherein a beam specific downlink dwell time (Di) and a beam specific downlink revisit time (Ri) are configured for each SSB index i, a SSB index i specific starting downlink dwell time is configured as SFN = Ai, and a SSB index i starting downlink dwell time is determined by SFN =Ai+k*Ri, where k=1, 2, ….18.The apparatus of claim 1, wherein the apparatus is part of a non-terrestrial network (NTN) .19.An apparatus comprising processing circuitry configured to:process, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time, a downlink revisit time, a downlink starting dwell time, and a time period for a first Random Access Response (RAR) window;generate, for transmission to the network, a physical random access channel (PRACH) request at a time slot n within an uplink dwell time according to the downlink starting dwell time;estimate a round trip time (RTT) for the PRACH request; andmonitor for a Random Access Response (RAR) during a second RAR window that is based on the RTT and the downlink dwell time.20.An apparatus comprising processing circuitry configured to:process, based on signals received from a network, beam-based configuration information, wherein the beam-based configuration information comprises a downlink dwell time, a downlink revisit time, and a downlink starting dwell time;determine a starting time of RAR window monitoring, based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time; anddetermine a downlink reception timing based on the configured downlink dwell time, downlink revisit time and downlink starting dwell time.

Images