TDD frame structure for IoT ntn

Abstract

The present disclosure generally relates to a time division duplexing (TDD) frame structure for Internet of Things (IoT) non-terrestrial network (NTN) communications. In accordance with aspects of the present disclosure, a user equipment (UE) may receive timing information associated with an IoT NTN TDD mode. The UE may determine an alignment between a narrowband IoT (NB-IoT) frame structure and a satellite frame structure based at least on the timing information. The UE may determine one or more subframes to monitor for downlink narrowband signals based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure.

Description

TDD FRAME STRUCTURE FOR IOT NTNTECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communication, and more specifically to a time-division duplexing (TDD) frame structure for Internet-of-Things (IoT) non-terrestrial network (NTN) communications.BACKGROUND

[0002] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and / or video data) , messaging, and / or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the wireless user devices using one or more wireless network protocols, such as protocols described in various telecommunication standards promulgated by the European Telecommunications Standards Institute (ETSI) Third Generation Partnership Project (3GPP) . The wireless communication networks facilitate mobile broadband service using technologies such as orthogonal frequency-division multiple access (OFDMA) , multiple-input multiple output (MIMO) , advanced channel coding, massive MIMO, beamforming, and / or other features.SUMMARY

[0003] The present disclosure generally relates to a time division duplexing (TDD) frame structure for Internet of Things (IoT) non-terrestrial network (NTN) communications. In some implementations, a user equipment (UE) receives timing information associated with an IoT NTN TDD mode. The UE may determine an alignment between a narrowband IoT (NB-IoT) frame structure and a satellite frame structure based at least on the timing information. The UE may determine one or more subframes to monitor for downlink narrowband signals based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure. In other implementations, a UE receives scheduling information associated with an IoT NTN TDD mode. The UE may identify one or more subframes that are available for NB-IoT communications based at least on the scheduling information. The UE may perform the NB-IoT communications during the one or more subframes in accordance with the IoT NTN TDD mode.

[0004] The details of one or more embodiments of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE FIGURES

[0005] FIG. 1 illustrates an example wireless network, according to some implementations.

[0006] FIG. 2 illustrates an example time division multiple access (TDMA) frame structure, according to some implementations.

[0007] FIG. 3 illustrates an example frequency division multiple access (FDMA) frame structure, according to some implementations.

[0008] FIG. 4 illustrates an example Internet of Things (IoT) non-terrestrial network (NTN) communication scheme, according to some implementations.

[0009] FIG. 5 illustrates another IoT NTN communication scheme, according to some implementations.

[0010] FIGs. 6A-6C illustrate an example frame structure for IoT NTN, according to some implementations.

[0011] FIGs. 7A-7C illustrate another example frame structure for IoT NTN, according to some implementations.

[0012] FIGs. 8A-8C illustrate another example frame structure for IoT NTN, according to some implementations.

[0013] FIGs. 9A-9C illustrate another example frame structure for IoT NTN, according to some implementations.

[0014] FIG. 10 illustrates another example frame structure for IoT NTN, according to some implementations.

[0015] FIGs. 11A-11C illustrate another example frame structure for IoT NTN, according to some implementations.

[0016] FIGs. 12A-12C illustrate another example frame structure for IoT NTN, according to some implementations.

[0017] FIGs. 13A-13C illustrate another example frame structure for IoT NTN, according to some implementations.

[0018] FIG. 14 illustrates an example physical random access channel (PRACH) transmission scheme, according to some implementations.

[0019] FIG. 15 illustrates an example paging scheme, according to some implementations.

[0020] FIGs. 16A-16B illustrate another example frame structure for IoT NTN, according to some implementations.

[0021] FIGs. 17-20 illustrate flowcharts of example methods for IoT NTN TDD, according to some implementations.

[0022] FIG. 21 illustrates an example user equipment (UE) , according to some implementations.

[0023] FIG. 22 illustrates an example access node, according to some implementations.DETAILED DESCRIPTION

[0024] In some wireless systems that support narrowband Internet-of-Things (NB-IoT) communications, a user equipment (UE) may receive downlink (DL) narrowband signals from a non-terrestrial access node (e.g., a satellite, and referred to hereinafter as a satellite) . For example, the satellite may periodically transmit at least one of a narrowband primary synchronization signal (NPSS) , a narrowband secondary synchronization signal (NSSS) , a narrowband physical broadcast channel (NPBCH) transmission, or a narrowband system information block 1 (SIB1-NB) . Additionally, the satellite may receive a narrowband physical random access channel (NPRACH) transmission from the UE. These narrowband signals can help the UE acquire and maintain synchronization with the satellite. In some implementations, the satellite may be configured to transmit all downlink narrowband signals in one slot of a satellite time division duplexing (TDD) frame structure. This slot may overlap with multiple subframes of an NB-IoT frame structure. In some cases, however, it may be unclear which subframe (s) to monitor for each reference signal type.

[0025] The present disclosure generally relates to an NB-IoT TDD frame structure for non-terrestrial network (NTN) communications. In accordance with the techniques described herein, the UE may determine an offset between a downlink slot of a satellite frame structure and a starting downlink subframe of an NB-IoT frame structure. In some implementations, the offset may have a fixed or pre-configured value. In other implementations, the offset may be indicated by the network (e.g., the satellite) . Once the UE has determined the starting downlink subframe of the NB-IoT frame structure, the UE may determine which downlink subframes to monitor for NPBCH, NPSS, NSSS, SIB1-NB, narrowband physical downlink control channel (NPDCCH) , narrowband physical downlink shared channel (NPDSCH) , etc. The UE may also determine which uplink (UL) subframes to use for NPRACH based on the starting DL subframe. For example, the UE may determine an offset between the starting DL subframe and a starting UL subframe of the NB-IoT frame structure.

[0026] FIG. 1 illustrates an example wireless network 100, according to some implementations. The wireless network 100 includes a UE 102 and a base station 104, which are connected via one or more channels 106A, 106B across an air interface 108. The UE 102 and base station 104 communicate using a system that supports controls for managing the access of the UE 102 to a network via the base station 104.

[0027] In some implementations, the wireless network 100 is a standalone (SA) network, e.g., that incorporates fifth generation (5G) New Radio (NR) . In some other implementations, the wireless network 100 is a non-standalone (NSA) network that incorporates Long Term Evolution (LTE) and 5G NR. In these implementations, the wireless network 100 may be an Evolved Universal Terrestrial Radio Access (E-UTRA) NR dual connectivity (EN-DC) network, or an NR-EUTRA dual connectivity (NE-DC) network. Furthermore, wireless networks implementing one or more other types of communication standards are possible, including future 3GPP systems (e.g., sixth generation “6G” ) , Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology, or the like. While aspects may be described herein using terminology commonly associated with 5G NR, aspects of the present disclosure can be applied to other systems, such as systems subsequent to 5G (e.g., 6G) .

[0028] In the wireless network 100, the UE 102 and any other UE in the system may be, for example, any of a laptop computer, smartphone, tablet computer, machine-type device (such as smart meters or specialized devices for healthcare) , intelligent transportation system, or any other wireless device. In the wireless network 100, the base station 104 provides the UE 102 network connectivity to a broader network (not shown) . This UE 102 connectivity is provided via the air interface 108 in a base station service area provided by the base station 104. In some implementations, such a broader network may be a wide area network operated by a cellular network provider, or may be the Internet. Each base station service area associated with the base station 104 is supported by one or more antennas integrated with the base station 104. The service areas can be divided into a number of sectors associated with one or more particular antennas. Such sectors may be physically associated with one or more fixed antennas or may be assigned to a physical area with one or more tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector.

[0029] The UE 102 includes control circuitry 110 coupled with transmit circuitry 112 and receive circuitry 114. The transmit circuitry 112 and receive circuitry 114 may each be coupled with one or more antennas. The control circuitry 110 may include application-specific circuitry, baseband circuitry, or any of various combinations thereof. The transmit circuitry 112 and receive circuitry 114 may be adapted to transmit and receive data, respectively, and may include radio frequency (RF) circuitry and / or front-end module (FEM) circuitry.

[0030] In various implementations, aspects of the transmit circuitry 112, receive circuitry 114, and / or control circuitry 110 may be integrated in various ways to implement the operations described herein. The control circuitry 110 may be adapted or configured to perform various operations, such as those described elsewhere in this disclosure related to a UE. For example, the control circuitry 110 can determine an alignment between an NB-IoT frame structure and a satellite frame structure based on scheduling information and / or timing information provided by the base station 104.

[0031] The transmit circuitry 112 can perform various operations described herein. For example, the transmit circuitry 112 can transmit a PRACH in one or more subframes that overlap with an uplink slot of a satellite frame structure. Additionally, the transmit circuitry 112 may transmit using a plurality of multiplexed UL physical channels. The plurality of UL physical channels may be multiplexed, e.g., according to time division multiplexing (TDM) or frequency division multiplexing (FDM) , and in some implementations, along with carrier aggregation (CA) . The transmit circuitry 112 may be configured to receive block data from the control circuitry 110 for transmission on the air interface 108.

[0032] The receive circuitry 114 can perform various operations described herein. For example, the receive circuitry 114 can receive at least one of an NPBCH, an NPSS, an NSSS, a SIB1-NB, a MIB-NB, a NPDCCH, or an NPDSCH in one or more subframes that overlap with a downlink slot of a satellite frame structure. Additionally, the receive circuitry 114 may receive a plurality of multiplexed DL physical channels from the air interface 108 and relay the physical channels to the control circuitry 110. The plurality of DL physical channels may be multiplexed, e.g., according to TDM or FDM, e.g., along with CA. The transmit circuitry 112 and the receive circuitry 114 may transmit and receive, respectively, both control data and content data (e.g., messages, images, video, and the like) structured within data blocks that are carried by the physical channels.

[0033] FIG. 1 also illustrates the base station 104. In some implementations, the base station 104 may be a 5G radio access network (RAN) , a next generation RAN, a E-UTRAN, a non-terrestrial cell, or a legacy RAN, such as a UTRAN. As used herein, the term “5G RAN” or the like may refer to the base station 104 that operates in an NR wireless network 100, and the term “E-UTRAN” or the like may refer to a base station 104 that operates in an LTE wireless network 100. The UE 102 utilizes connections (or channels) 106A, 106B, each of which includes a physical communications interface or layer.

[0034] The base station 104 circuitry may include control circuitry 116 coupled (directly or indirectly) with transmit circuitry 118 and / or receive circuitry 120. The transmit circuitry 118 and receive circuitry 120 may each be coupled (directly or indirectly) with one or more antennas that may be used to enable communications via the air interface 108. The transmit circuitry 118 and receive circuitry 120 may be adapted to transmit and receive data, respectively, addressed to any UE connected to the base station 104. The receive circuitry 120 may receive a plurality of UL physical channels from one or more UEs, including the UE 102.

[0035] In FIG. 1, the one or more channels 106A, 106B are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as an LTE protocol, advanced LTE (LTE-A) protocol, LTE-based access to unlicensed spectrum (LTE-U) , NR protocol, NR-based access to unlicensed spectrum (NR-U) protocol, and / or any other communications protocol (s) . In some implementations, the UE 102 may directly exchange communication data via a ProSe interface. The ProSe interface may alternatively be referred to as a sidelink interface and may include one or more logical channels, including but not limited to a physical sidelink control channel (PSCCH) , a physical sidelink discovery channel (PSDCH) , and a physical sidelink broadcast channel (PSBCH) .

[0036] The wireless network 100 may support an IoT NTN TDD mode based on an NB-IoT NTN FDD frame structure. This IoT NTN TDD mode may use a TDD pattern with a period of 9 radio frames for a target mobile satellite service (MSS) allocated band, where D=U=8 with a fixed guard period. The IoT NTN TDD mode can also support an adjustable guard period for the purpose of allowing deployment with the TDD frame structure of the legacy system operating in the target MSS allocated band. The IoT NTN TDD mode can be used for low earth orbit (LEO) at 600 km and 1200 km orbit respectively, with set-1 satellite parameters as reference scenarios. These parameters are defined in 3GPP TR 36.763.

[0037] In some implementations, the IoT NTN TDD mode targets the 1616-1626.5 megahertz (MHz) MSS allocated band for standalone deployments with anchor and non-anchor carriers (e.g., operating in carriers used for NB-IoT) . Some IoT NTN devices operate in an Earth fixed Tracking area, with either Earth fixed cells or Earth moving cells for non-geosynchronous orbit (NGSO) communications. The NB-IoT NTN TDD mode described herein supports configuring the usage of radio resources in the targeted MSS allocated band with a periodic subset of UL and DL subframes in N radio frames. The periodic pattern can include a non-overlapping set of usable contiguous UL subframes (U) , a set of usable contiguous DL subframes (D) , and periodic guard periods every N radio frames, with N=9 for the target MSS allocated band.

[0038] FIG. 2 illustrates an example time division multiple access (TDMA) frame structure 200, according to some implementations. The TDMA frame structure 200 of FIG. 2 includes a number of UL subframes and a number of DL subframes. Some wireless communication systems that operate in LEO (780 km orbit) target an operating band of 1610-1626.5MHz. These wireless communication systems can use a hybrid TDMA or frequency division multiple access (FDMA) architecture based on TDD with a 90ms frame. In these systems, a channel assignment may include a frequency carrier and a time slot.

[0039] FIG. 3 illustrates an example FDMA frame structure 300, according to some implementations. The basic unit of the FDMA frame structure 300 is a frequency access band (41.667kHz) . For a Duplex Channel band, one sub-band includes 8 frequency accesses (e.g., 8 *41.667kHz = 333.333kHz) . In the example shown, there are 30 sub-bands from 1616MHz to 1626MHz. For a Simplex Channel band, there are 12 frequency access bands (500kHz) between 1626MHz and 1626.5MHz. In the time domain, resources are partitioned into slots that each span 8.28 ms.

[0040] FIG. 4 illustrates a resource diagram of an example IoT NTN communication scheme 400, according to some implementations. The resource diagram of FIG. 4 includes several IoT NTN channels. Some IoT-NTN DL channel patterns are fixed or preconfigured. For example, NPSS may be transmitted every 10ms in subframe#5, and NSSS may be transmitted every 20ms in subframe#9. Four NSSS sequences with different cyclic shifts may be transmitted in 80ms. In some implementations, NPBCH is transmitted every 10ms in subframe#0. NPBCH may include 8 independently decodable blocks spanning 80ms. In some implementations, MIB content remains unchanged for 640ms. SIB1-NB transmission may occur in subframe#4 of every other frame in 16 continuous frames with a fixed periodicity of 2560ms.

[0041] The IoT NTN communication scheme 400 of FIG. 4 uses an IoT-NTN UL channel pattern for PRACH, which includes 4 symbol groups. For NPRACH format 0, one symbol group is 2048Ts CP + 5 *8192Ts Tseq = 6.4ms, and the PRACH duration is 6.4 *4 = 25.6ms. For NPRACH format 1, one symbol group is 8192Ts CP + 5 *8192Ts Tseq = 5.6ms, and the PRACH duration is 5.6 *4 = 22.4ms.

[0042] The IoT NTN communication scheme 400 of FIG. 4 supports operation within the same band as the TDD frame structure of legacy system in the 1.6GHz MSS band. At the satellite, all DL NB-IoT channels / signals in a cell can use one of the DL slots in the TDD frame structure (DL1, DL2, DL3 or DL4) across 90ms periods. The same DL slot may be used in all the 90ms periods. At the satellite, all UL NB-IoT channels in a cell can use one of the UL slots in the TDD frame structure (UL1, UL2, UL3 or UL4) across 90ms periods. The same UL slot may be used in all the 90ms periods. The one UL slot and one DL slot in the TDD frame structure can have the same index (e.g., DL1 &UL1, DL2 &UL2, DL3 &UL3, or DL4 &UL4) . However, other configurations are possible. The DL subframes within D=8 can be down-selected from the following options. Option 1: [3 4 5 6 7 8 9 0] (across two consecutive radio frames) . Option 2: [4 5 6 7 8 9 0 1] (across two consecutive radio frames) . Option 3: [8 9 0 1 2 3 4 5] (across two consecutive radio frames) . Option 4: [9 0 1 2 3 4 5 6] (across two consecutive radio frames) .

[0043] In the IoT NTN communication scheme 400 of FIG. 4, an offset may be configured between a 90ms TDD structure and a 10240ms hyper system frame number (H-SFN) . In some implementations, this offset is the same across H-SFNs. In some implementations, the H-SFN duration is changed to X radio frames, where X is a multiple of 9. In some implementations, the H-SFN duration is unchanged. In other implementations, the offset is different across some H-SFNs. In some implementations, the offset between H-SFN and 90ms TDD structure is indicated by a DL signal (e.g., one of NPSS / NSSS / NPBCH / SIB1-NB) . In some implementations, the total number of H-SFN is changed to be a multiple of 9.

[0044] In some implementations, NPUSCH overlaps with non-U NB-IoT subframes and NPRACH (including NPRACH occasions) overlap with non-U NB-IoT subframes. New periodicities may align with the TDD structure. In some implementations, a channel is postponed when it overlaps with non-U NB-IoT subframes. In other implementations, a channel is restricted to be fully confined within a single set of U NB-IoT subframes. In other implementations, a channel is dropped (fully or partially) when it overlaps with non-U NB-IoT subframes. This can impact segmented pre-compensation.

[0045] In some implementations, NPDCCH / NPDSCH (other than the one carrying SIB1-NB) overlaps with non-D NB-IoT subframes, including, e.g., the starting point, windows for system information or random access response (RAR) and other window sizes for DL channels / signals, paging occasions (PO) , and the like. In some implementations, new periodicities align with the TDD structure. In some implementations, a channel is postponed when it overlaps with non-D NB-IoT subframes. In other implementations, a channel is restricted to be fully confined within a single set of D NB-IoT subframes. In other implementations, a channel is dropped (fully or partially) when it overlaps with non-D NB-IoT subframes. As described herein, non-D NB-IoT subframes are not “NB-IoT DL subframes, ” as defined by 3GPP.

[0046] Existing TDD schemes may face one or more of the following issues. Only some DL subframes and UL subframes in the 90ms TDD structure can be used for DL and UL transmission, which makes it challenging to schedule DL and UL transmissions. Also, current PDCCH periods, PP, may not be enough to transmit NPDCCH with a 90ms periodicity. The periodicity is determined by T = Rmax *G, where G = {1.5, 2, 4, 8, 16, 32, 48, 64} , and Rmax = {1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048} . For TDD mode, there are 8 DL subframes for NPDCCH every 90ms period, including NPBCH, NPSS, NSSS, and SIB1-NB. As such, only 4 subframes are left for data transmission. If Rmax = 8 and G = 16, then T = 128ms, but 8 repetitions would span at least 2 *90ms. If G is smaller than 32, this configuration may not support NPDCCH with a 90ms TDD structure. Additionally, there may be scheduling restrictions on system information and paging. Also, it may be unclear how to determine the offset between the 90ms TDD structure and the 10240ms H-SFN.

[0047] Furthermore, it may be unclear how to determine which DL subframes are compatible with satellite DL slot (s) , and which DL subframe is the starting subframe in a satellite DL slot. Likewise, it may be unclear which TDD pattern aligns with the satellite frame structure. PBCH / NPSS / NSSS may be configured to support co-existence with in-obit satellites. With the current PBCH / NPSS / NSSS transmission period, it may be unclear how to configure the on DL period for the UE to synchronize with the network. NSSS is transmitted every 20ms, and if the DL duty cycle is 1 / N, e.g., 10ms every N radio frame, the UE may not have an opportunity to read the NSSS. NPBCH can be transmitted within 640ms period. If the SIB1-NB repetition number is 16, the UE can receive an entire SIB1-NB transport block (TB) in 2560ms. However, the UE may be unable to do so for other repetition numbers. Changes to the NPRACH transmission periodicity and starting subframe may be needed to adapt the existing NPRACH design for in-obit satellite coexistence.

[0048] FIG. 5 illustrates a resource diagram of another IoT NTN communication scheme 500, according to some implementations. In FIG. 5, each frequency resource spans 41.667 kHz, and each sub-band includes 8 frequency resources (333.333 kHz) . Each frame spans 8.28ms. The resource diagram of FIG. 5 includes a number of multiplexed simplex time slots associated with respective channel numbers ranging from 1 to 12. For example, a simplex time slot located at 1626 MHz may be associated with channel number 1, and a simplex time slot located at 1626.5 MHz may be associated with channel number 12.

[0049] With existing TDD schemes, it may be unclear which DL subframes are compatible with which satellite DL slots. The IoT NTN communication scheme 500 of FIG. 5 uses an DL subframe offset for subframe boundary determination. In some implementations, the DL subframe pattern for DL synchronization is fixed in 90ms periodicity. For example, the subframe pattern can be Option 1 shown in FIG. 5, e.g., subframe #3, …#9 and subframe#0. In some implementations, the network indicates the subframe offset of the starting DL subframe, which ensures that DL subframes (including NPSS, NSSS, NPBCH and SIB1-NB ) align with satellite DL slot (s) .

[0050] In some implementations, the subframe offset indication is provided via MIB-NB. X bits (e.g., 3, 4 or 5 bits) can be introduced to an subframe offset field in MIB-NB, or the current field can be reinterpreted, or spare bits can be used to indicate the subframe offset. The number of bits X may be related to the NSSS design. In other implementations, the subframe offset indication is provided via SIB-NB. If multiple satellite DL slots are allocated for NB-IoT usage, the subframe offset and the number of subframes can be used for additional DL transmission. The subframe offset may be relative to the first DL subframe of the DL subframe pattern for DL synchronization. Alternatively, the network can indicate the satellite DL slot index, which is associated with IoT NPSS / NSSS / NPBCH subframes.

[0051] In the frame structure 600 (shown in FIGs. 6A-6C) , the subframes corresponding to satellite DL slot 2 are used for NB-IoT DL transmission and synchronization. After the UE detects the NPBCH to get MIB, or after decoding SIB1-NB, the UE can determine that the subframe offset is 2ms. With this information, the UE can determine that subframe 3 to 9 of SFN 6 and subframe 0 of SFN7 are used for DL transmission. If the offset is 3ms, subframe 4 to 9 of SFN6 and subframe 0 and 1 in SFN 7 can be used for DL transmission. In some implementations, the network indicates which option is applied for DL transmission and synchronization. Options 1, 2, 3, and 4 are shown in FIG. 5.

[0052] A UL subframe offset can be used for UL subframe boundary determination. For example, a set of subframes for DL transmission in a satellite slot can be associated with a set of UL subframes for UL transmission. In some implementations, the subframe offset between the UL subframe set and the DL subframe set, and the number of subframes in the UL subframe set may be fixed or preconfigured. In other implementations, the network indicates the subframe offset and the number of subframes in an UL subframe set via MIB or SIB1-NB. The network can indicate additional UL and DL subframe sets, except the basic subframe set for DL synchronization. The indication from the network may include the subframe offsets and number of subframes for DL and UL transmissions. The offsets can be relative to the starting subframe of the basic DL subframe set. Alternatively, the UL subframe offset can be relative to the basic UL subframe set, and the DL subframe offset can be relative to the basic DL subframe set. The additional DL subframe set, which can include NPSS, NSSS, NPBCH, or SIB1-NB, may be configured by the network.

[0053] FIGs. 6A-6C illustrate an example frame structure 600 for IoT NTN, according to some implementations. The frame structure 600 shows the alignment between a satellite frame structure and an NB-IoT frame structure. The satellite frame structure includes a simplex time slot that spans 20.32ms, four uplink slots (UL1, UL2, UL3, UL4) that each span 8.28ms, and four downlink slots (DL1, DL2, DL3, DL4) that each span 8.28ms. The NB-IoT frame structure is partitioned into 9 frames (SFN 0-8) that each include 10 subframes. In the example shown, subframe 0 is allocated for NPBCH, subframes 1-3 and 6-8 are allocated for NPDCCH / NPDSCH, subframe 4 is allocated for SIB1-NB, subframe 5 is allocated for NPSS, and subframe 9 is allocated for NSSS. There is a 2ms gap between the end of slot DL4 (satellite) and the end of SFN8 (NB-IoT) .

[0054] FIGs. 7A-7C illustrate another example frame structure 700 for IoT NTN, according to some implementations. The frame structure 700 shows a TDD pattern with a 9 radio frame structure including DL subframes, a gap, and UL subframes that are compatible with in-orbit satellites. In some implementations, the network indicates the subframe index for UL and DL transmissions, and / or the gap. In other implementations, the gap is implicitly determined by the UE.

[0055] FIGs. 8A-8C illustrate another example frame structure 800 for IoT NTN, according to some implementations. The frame structure 800 shows the alignment between a satellite frame structure and an NB-IoT TDD pattern. The satellite frame structure includes a simplex time slot that spans 20.32ms, four uplink slots (UL1, UL2, UL3, UL4) that each span 8.28ms, and four downlink slots (DL1, DL2, DL3, DL4) that each span 8.28ms. The NB-IoT TDD pattern is implemented across 9 frames (SFN 0-8) , each frame including 10 subframes. In the example shown, all subframes that overlap with UL2 are allocated for NPUSCH, and subframes that overlap with DL2 are allocated for NPBCH, NPSS, NSSS, SIB1-NB, and NPDCCH / NPDSCH. The frame structure 800 shows a flexible TDD pattern where the first UL subframe in the continuous UL resources is indicated by an offset relative to detected DL subframes, e.g. NPSS, NSSS, or NPBCH.

[0056] FIGs. 9A-9C illustrate another example frame structure 900 for IoT NTN, according to some implementations. The frame structure 900 shows the alignment between a satellite frame structure and an NB-IoT TDD pattern. The satellite frame structure includes a simplex time slot that spans 20.32ms, four uplink slots (UL1, UL2, UL3, UL4) that each span 8.28ms, and four downlink slots (DL1, DL2, DL3, DL4) that each span 8.28ms. The NB-IoT TDD pattern is implemented across 9 frames (SFN 0-8) , each frame including 10 subframes. In the example shown, all subframes that overlap with UL1 are allocated for NPUSCH, subframes that overlap with DL1 are allocated for NPDCCH / NPDSCH, and subframes that overlap with DL3 are allocated for NPBCH, NPSS, NSSS, SIB1-NB, and NPDCCH / NPDSCH. In the example shown, there is an association between satellite UL and DL slots. The UE may implement this TDD pattern using information associated with the satellite frame structure. This information can be provided by the network or implicitly derived by the UE. The UE should know the gap between simplex slots and UL slots, the gap between UL slots, the gap between DL slots, etc.

[0057] In some implementations, the network configures the satellite UL slot 2 for NB-IoT UL transmission and configures the satellite DL slot 2 for NB-IoT DL transmission. A time offset may be present between the starting point of the satellite frame structure and the NB-IoT TDD mode pattern. The offset can have an increment of 0.01ms and a maximum value of 10ms. The offset can be fixed (e.g., preconfigured) or configured by the network. According to the time offset, the UE can determine the number of UL subframes in a satellite UL slot and the number of DL subframes in a satellite DL slot. If the offset is in the range of {-0.62, -0.58} , the UL and DL pair of slot 1 (UL1 and DL1) and slot 3 have 8 subframes for DL and 8 subframes for UL. If the offset is in the range of {-0.84, -0.63} , the slot 1 pair (UL1 and DL1) has 8 subframes for DL and 8 subframes for UL. If the offset is in the range of {-0.24, -0.06} , the slot 2 pair has 8 subframes for DL and 8 subframes for UL. If the offset is in the range of {-0.57, -0.56} , the slot 3 pair has 8 subframes for DL and 8 subframes for UL. For other offset values, each DL slot or UL slot may have 7 DL subframes or 7 UL subframes, respectively.

[0058] Some aspects of the present disclosure relate to scheduling enhancements, including DL and UL scheduling enhancements, for IoT NTN TDD mode. In some implementations, the network indicates the valid DL subframes and valid UL subframes over 90ms for an anchor carrier. The indication can start from SFN 0 of H-SFN#0, and the same indication can be applied every 90ms periodicity. DL transmissions may be limited to valid DL subframes. If a DL subframe is invalid, DL transmissions may be postponed to the next available valid DL subframe. In some implementations, subframes that have NPSS / NSSS / NPBCH / SIB1-NB are invalid subframes. UL transmissions may be limited to valid UL subframes. If an UL subframe is invalid, UL transmissions may be postponed to the next available valid UL subframe.

[0059] In some implementations, the indication of which subframes are valid can be provided via MIB or SIB1-NB. For example, a bitmap can be applied to indicate valid UL and DL subframes within a 90ms TDD structure, assuming no offset between the satellite frame structure and the NB-IoT TDD pattern. In some implementations, the bitmap indicates the valid UL subframes and valid DL subframes within a 90ms periodicity. In such cases, the bitmap may include 90 bits. In other implementations, an 8-bit bitmap indicates the valid satellite UL slot (s) and valid satellite DL slot (s) . 4 bits may be used to indicate 4 UL slots, and 4 bits may be used to indicate 4 DL slots. The network can indicate the valid DL subframes and valid UL subframes over 90ms for non-anchor carrier (s) .

[0060] The present disclosure supports scheduling enhancements for NPDCCH monitoring in IoT NTN TDD mode. In some implementations, the maximum number of NPDCCH repetitions is limited to 64, and Rmax may be selected from {1, 2, 4, 8, 16, 32, 64} . The NPDCCH period, e.g., PP, can be extended by expanding the range of G to include the following values: {90, 128, 180, 256} in addition to the existing values of {1.5, 2, 4, 8, 16, 32, 48, 64} . If G is smaller than 32, the UE may assume that an error has occurred. In some implementations, only the additional G values of {90, 128, 180, 256} are valid for IoT NTN TDD mode with 90ms periodicity. K0 is the starting subframe of an NPDCCH search space, as defined in 3GPP TS 36.213. If K0 is configured in an invalid subframe, K0 can be delayed to a valid DL subframe. Alternatively, the UE may consider this scenario an error case. If PDCCH search spaces overlap due to postponed transmission (s) , the UE may consider the scenario an error case. Otherwise, the UE may drop the second search space and refrain from monitoring PDCCH candidates in the second search space.

[0061] Some aspects of the present disclosure relate to system information scheduling enhancements for system information message acquisition. In some implementations, the system information window starts at subframe #0 in the radio frame for which (H-SFN *1024 + SFN) mod T = FLOOR (x / 10) + Offset, where T is the si-Periodicity of the system information message and Offset is the offset of the start of the system information window (si-RadioFrameOffset) . The parameter si-WindowLength-r13 may be set to one of the following values: {ms160, ms320, ms480, ms640, ms960, ms1280, ms1600, spare1} . The parameter si-RepetitionPattern indicates the starting radio frames within the system information window used for system information message transmission. A value of every2ndRF corresponds to every 2 radio frames, a value of every4thRF corresponds to every 4 radio frames, and so on. The first transmission of the system message may be transmitted from the first radio frame of the system information window. The parameter si-RepetitionPattern-r13 may be set to one of the following values: {everyRF, every2ndRF, every4thRF, every8thRF} .

[0062] As explained in 3GPP TS, 36.331, a UE may receive and accumulate system information message transmissions on a downlink shared channel (DL-SCH) from the start of the system information window and continue until the end of the system information window, whose absolute length in time is given by si-WindowLength, starting from the radio frames as provided in si-RepetitionPattern and in subframes as provided in downlinkBitmap, or until successful decoding of the accumulated system information message transmissions excluding the subframes used for transmission of NPSS, NSSS, MIB-NB / MIB-TDD-NB and SIB-NB. If there is an insufficient number of subframes for one system information message transmission in the radio frames, as provided by si-RepetitionPattern, the UE continues to receive the system information message transmission in the radio frames following the radio frame indicated by si-RepetitionPattern.

[0063] If there is an insufficient number of valid subframes in the 90ms TDD structure (e.g., not enough subframes for a system information message transmission) , the UE may continue to receive the system information message transmission in the next available valid subframes. For the system information repetition pattern, repetition of system information may be disabled for IoT NTN TDD mode. Alternatively, new SI repetition patterns, e.g., every 90ms, every 180ms, every 360ms, may be introduced.

[0064] In some implementations, an offset can be added between the 90ms TDD structure and the 10240ms H-SFN structure. The offset between the 90ms TDD structure and the H-SFN structure can vary for different H-SFN indexes. Subframe-level alignment can be used to achieve the target of one satellite slot (8.28ms) including 8ms IoT NTN subframes. The units of the offset can range from 0.01ms to 10ms. Depending on the alignment with satellite DL / UL slots, the offset can be determined according to the gaps between DL slots, the gaps between UL slots, or the gaps between DL and UL slots. An offset of 0.58ms may enable 8 UL subframes in satellite slot 1 and slot 3, and 8 DL subframes in slot 1 and slot 3.

[0065] FIG. 10 illustrates another example frame structure 1000 for IoT NTN, according to some implementations. The frame structure 1000 of FIG. 10 includes a first frame (SFN0) and a second frame (SFN1) of an NB-IoT frame structure. SFN0 and SFN1 each include 10 subframes. In the example shown, subframe 0 is allocated for NPBCH, subframe 4 is allocated for SIB1-NB, subframe 5 is allocated for NPSS, subframe 9 is allocated for NSSS, and subframes 1-3 and 6-8 are allocated for NPDCCH / NPDSCH.

[0066] FIGs. 11A-11C illustrate another example frame structure 1100 for IoT NTN, according to some implementations. The frame structure 1100 of FIG. 11 shows an enhanced NPSS / NSSS / NPBCH design and TDD pattern that aligns with a satellite frame structure. If the NPSS transmission periodicity is 10ms, the UE can assume there are multiple NPSS transmissions in a 90ms period. In such cases, transmission may be limited to the satellite DL slot (s) , if configured for DL transmission. If the NPSS transmission periodicity is 90ms, there may be one NPSS transmission in a 90ms period. If the NPBCH transmission periodicity is 10ms, the UE may assume there are multiple NPBCH transmissions in a 90ms period. In such cases, transmission may be limited to the satellite DL slot (s) , if configured for DL transmission. If the NPBCH transmission periodicity is 90ms, there may be one NPBCH transmission in a 90ms period.

[0067] In some implementations, NSSS is transmitted in subframe 9 in every radio frame. The NSSS transmission periodicity can be 10ms, and the sequence pattern periodicity can be kept at 80ms to get the 80ms frame information. The cyclic shift θf in frame number nf can be determined by This ensures that one NSSS is transmitted every 90ms. Additional NSSS may be transmitted if the network configures transmission on other DL slots. In other implementations, the NSSS transmission periodicity is 20ms, and more NSSS can be transmitted if more DL slots are configured for DL transmission. In other implementations, the NSSS transmission periodicity is 90ms, there is at most one NSSS every 90ms, and it is possible that no NSSS is transmitted in a specific 90ms periodicity. An example of this is shown in FIGs. 11A-11C, where NPSS, NSSS, and NPBCH are transmitted with 90ms periodicity.

[0068] FIGs. 12A-12C illustrate another example frame structure 1200 for IoT NTN, according to some implementations. The frame structure 1200 shows a SIB1-NB design that supports co-existence with in-orbit satellites. In some implementations, one SIB1-NB transmission block (TB) occupies 8 total subframes. The distribution of the 8 subframes can be determined as follows. In some implementations, SIB1-NB is mapped to subframe 4 in a radio frame of 90ms period, and the whole SIB1-NB block is transmitted in 720ms. In the example shown, only one DL satellite slot is used for SIB1-NB transmission.

[0069] FIGs. 13A-13C illustrate another example frame structure 1300 for IoT NTN, according to some implementations. The frame structure 1300 shows another SIB1-NB design that supports co-existence with in-orbit satellites. In some implementations, the network configures the number of DL satellite slots (8.28ms) in 90ms to be used for SIB1-NB transmission. For example, if the network configures x slots, the whole SIB1-NB block may be transmitted in ceil (8 / x) *90ms. In some implementations, a new field can be added to MasterINformationBlock-NB (e.g., MIB) to indicate the DL satellite slots that are used for SIB1-NB transmission, as well for NPDSCH data transmission. In other implementations, spare bits can be used to indicate the DL satellite slots that are used for SIB1-NB transmission, or the existing field can be reinterpreted to convey the SIB1-NB transmission indication. For example, a bitmap of 4 bits can be used to indicate a SIB1-NB transmission. In some implementations, the indication of the DL satellite slots for SIB1-NB indicates how many SIB-NB subframes and / or locations of the SIB-NB subframes within the 90ms period.

[0070] In some implementations, SIB1-NB supports 4, 8, or 16 repetitions, according to the RRC information element (IE) schedulingInfoSIB1 defined in 3GPP TS 38.331, within a longer period m *90ms, where m is a fixed value (e.g., 256) . In other implementations, SIB1-NB may not support repetitions. In this scenario, the schedulingInfoSIB1 IE in MIB can be reinterpreted, and the UE may assume there is one transmission for SIB1-NB. The scheduling information can indicate the transport block size (TBS) selection, e.g., SIB1-NB is transmitted in 720ms within a 2560 period.

[0071] SIB1-NB may indicate the UL subframes used for NB-IoT transmission. In some implementations, SIB1-NB indicates the satellite slot index number (s) for IoT UL transmission, e.g., using a bitmap of 4 bits. In other implementations, SIB1-NB indicates (i) the relative subframe offset from the first DL subframe including NPSS / NSSS / NPBCH and / or (ii) the number of consecutive UL subframes used for UL transmission. SIB1-NB can indicate additional DL subframe (s) for NB-IoT transmission, except for those carrying NPBCH / NPSS / NSSS. In some implementations, SIB1-NB indicates the satellite slot index number (s) for IoT DL transmission, e.g., using a bitmap of 4 bits. In other implementations, SIB1-NB indicates (i) the relative subframe offset from the first DL subframe including NPSS / NSSS / NPBCH and / or (ii) the number of consecutive DL subframes used for DL transmission.

[0072] FIG. 14 illustrates an example PRACH transmission scheme 1400, according to some implementations. The PRACH transmission scheme 1400 shows an enhanced PRACH configuration that supports in-orbit satellite communication. In some implementations, 7 or 8 continuous UL subframes are available for UL transmission for NTN or in one satellite UL slot, where one symbol group occupies 6.4ms and 5.6ms for PRACH format 0 and format 1, respectively. One PRACH symbol group may be transmitted in one UL slot (or one UL subframe set) . In some implementations, a new PRACH periodicity can be selected from the following list: {360, 720, 1080, 1440, 2160, 2880} ms.

[0073] SIB1-NB can indicate the UL resources for PRACH transmission. In some implementations, SIB1-NB indicates the location and length of the UL subframe set. This location may be relative to the first subframe of the DL slot set for synchronization. Alternatively, SIB1-NB can indicate the satellite slot index number (s) for IoT PRACH transmission, e.g., using a bitmap of 4 bits, provided the UE can determine the UL slot location (s) . If UL resources are not configured for PRACH transmission, the UE may assume that satellite UL slot (s) associated with a DL slot for synchronization can be used for PRACH transmission.

[0074] The UE can receive an indication of the UL subframes in a UL subframe set for PRACH transmission. In some implementations, the network indicates the subframe offset for NPRACH transmission in a satellite UL slot, and the offset is applied to all the symbol groups. The offset may be relative to the starting subframe in the satellite UL slot or the starting subframe in the satellite DL slot including NPSS / NSSS / NPBCH. If the configured subframes for NPRACH transmission do not include a whole symbol group, the UE can drop the entire PRACH transmission, e.g., all four symbol groups are dropped. Alternatively, the UE may consider this scenario as an error case.

[0075] FIG. 15 illustrates an example paging scheme 1500, according to some implementations. The paging scheme 1500 of FIG. 15 supports paging scheduling enhancements. NB-IoT paging configurations are defined in 3GPP TS 36.331. The PCCH-Config-NB parameter (in SIB2-NB) may include the following fields: defaultPagingCycle-r13 and nB-r13. The defaultPagingCycle-r13 field can have one of the following values: rf128, rf256, rf512, rf1024. The nB-r13 field can have one of the following values: fourT, twoT, oneT, halfT, quarterT, one8thT, one16thT, one32ndT, one64thT, one128thT, one256thT, one512thT, one1024thT, spare3, spare2, spare1. The nB-r13 field indicates the number of paging frames in a paging cycle.

[0076] NB-IoT UE paging reception techniques are defined in 3GPP TS 36.304. A paging frame (PF) is determined according to SFN mod T = (T div N) * (UE_ID mod N) . A paging occasion (PO) is determined according to i_s= floor (UE_ID  / N) mod Ns, where T is the discontinous reception (DRX) cycle of the UE, N is equal to min (T, nB) , and Ns is equal to max (1, nB  / T) . For IoT NTN TDD mode, there are 8 DL subframes every 90ms that can be configured as a PO. Other frames / subframes are invalid. For example, as shown in FIG. 15, T = 128 frames in a default paging cycle, N = min (T, nB) = min (128, 128 / 4) = 32, so there are 16 PFs per 1280ms. In this scenario, the PO does not match the DL subframes of the 90ms TDD structure. To address this issue, if a PF or PO does not include valid DL subframes, the UE monitors NPDCCH for paging from the next available NPDCCH occasion in the valid DL subframe. Alternatively, if the PO is not a valid DL subframe, the first valid DL subframe after the PO is the starting subframe of the NPDCCH repetitions.

[0077] FIGs. 16A-16B illustrate another example frame structure 1600 for IoT NTN, according to some implementations. As described with reference to FIGs. 9A-9C, an offset between a 90ms IoT NTN TDD structure and a 10240ms H-SFN frame structure may be introduced to maintain frame structure alignment. For SFN-level alignment, even if there is alignment at SFN=0 of H-SFN#0, the starting point of the 90ms TDD structure may have 2 frames offset with SFN=0 of H-SFN#1 after one H-SFN. To address this issue, an offset with a specific H-SFN can be indicated via MIB-NB or SIB1-NB. The offset range can include {0, 1, 2, 3, 4, 5, 6, 7, 8} radio frame (s) . For MIB-NB, 6 spare bits or 5 spare bits in a Standalone-NB can be used to indicate the offset. In other implementations, the UE can read NSSS and MIB-NB to obtain the SFN number and the two least significant bits (LSB) of the H-SFN. Thereafter, the UE can read SIB1-NB to get the 8 most significant bits (MSB) of the H-SFN. With this information, the UE can acquire the H-SFN index. The offset can be determined by comparing it with the SFN index of the starting frame of the 90ms TDD structure.

[0078] FIG. 17 illustrates a flowchart of an example method 1700 for IoT NTN TDD, according to some implementations. For clarity of presentation, the method 1700 is described in the context of the preceding figures. For example, the method 1700 can be performed by a UE (such as the UE 102 of FIG. 1) , or any suitable system, environment, software, hardware, or combination thereof. In some implementations, operations of the method 1700 can be run in parallel, in combination, in loops, or in any order. The example method 1700 shown in FIG. 17 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 17) , which can be performed in the order shown or in a different order.

[0079] At 1702, the UE receives timing information associated with an IoT NTN TDD mode.

[0080] At 1704, the UE determines an alignment between a NB-IoT frame structure and a satellite frame structure based on the timing information.

[0081] At 1706, the UE determines one or more subframes to monitor for downlink narrowband signals based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure.

[0082] FIG. 18 illustrates a flowchart of an example method 1800 for IoT NTN TDD, according to some implementations. For clarity of presentation, the method 1800 is described in the context of the preceding figures. For example, the method 1800 can be performed by a UE (such as the UE 102 of FIG. 1) , or any suitable system, environment, software, hardware, or combination thereof. In some implementations, operations of the method 1800 can be run in parallel, in combination, in loops, or in any order. The example method 1800 shown in FIG. 18 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 18) , which can be performed in the order shown or in a different order.

[0083] At 1802, the UE receives scheduling information associated with an IoT NTN TDD mode.

[0084] At 1804, the UE identifies one or more subframes that are available for NB-IoT communications based at least on the scheduling information.

[0085] At 1806, the UE performs the NB-IoT communications during the one or more subframes in accordance with the IoT NTN TDD mode.

[0086] FIG. 19 illustrates a flowchart of an example method 1900 for IoT NTN TDD, according to some implementations. For clarity of presentation, the method 1900 is described in the context of the preceding figures. For example, the method 1900 can be performed by a base station (such as the base station 104 of FIG. 1) , or any suitable system, environment, software, hardware, or combination thereof. In some implementations, operations of the method 1900 can be run in parallel, in combination, in loops, or in any order. The example method 1900 shown in FIG. 19 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 19) , which can be performed in the order shown or in a different order.

[0087] At 1902, the base station transmits timing information associated with an IoT NTN TDD mode.

[0088] At 1904, the base station determines an alignment between a NB-IoT frame structure and a satellite frame structure based on the timing information.

[0089] At 1906, the base station transmits downlink narrowband signals in one or more subframes based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure.

[0090] FIG. 20 illustrates a flowchart of an example method 2000 for IoT NTN TDD, according to some implementations. For clarity of presentation, the method 2000 is described in the context of the preceding figures. For example, the method 2000 can be performed by a base station 104 (such as the base station 104 of FIG. 1) , or any suitable system, environment, software, hardware, or combination thereof. In some implementations, operations of the method 2000 can be run in parallel, in combination, in loops, or in any order. The example method 2000 shown in FIG. 20 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 20) , which can be performed in the order shown or in a different order.

[0091] At 2002, the base station transmits scheduling information associated with an IoT NTN TDD mode.

[0092] At 2004, the base station identifies one or more subframes that are available for NB-IoT communications based at least on the scheduling information.

[0093] At 2006, the base station performs the NB-IoT communications during the one or more subframes in accordance with the IoT NTN TDD mode.

[0094] FIG. 21 illustrates an example UE 2100, according to some implementations. The UE 2100 may be similar to and substantially interchangeable with UE 102 of FIG. 1. The UE 2100 may include any mobile or non-mobile computing device, such as, for example, a mobile phone, computer, tablet, industrial wireless sensors, video device (for example, cameras, video cameras, and the like) , wearable devices (for example, a smart watch) , relaxed internet-of-things (IoT) devices, etc.

[0095] The UE 2100 may include any / all of processor 2102, RF interface circuitry 2104, memory / storage 2106, user interface 2108, sensors 2110, driver circuitry 2112, power management integrated circuit (PMIC) 2114, one or more antenna (s) 2116, and battery 2118. The components of the UE 2100 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 21 is intended to show a high-level view of some of the components of the UE 2100. However, some of the components shown may be omitted, additional components may be present, and a different arrangement of the components shown may occur in other implementations.

[0096] The components of the UE 2100 may be coupled with various other components over one or more interconnects 2120, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, or optical connection that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0097] The processor 2102 may include one or more processors. For example, the processor 2102 may include processor circuitry such as, for example, baseband (BB) processor circuitry 2122A, central processor unit (CPU) circuitry 2122B, and graphics processor unit (GPU) circuitry 2122C. The processor 2102 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 2106 to cause the UE 2100 to perform operations as described herein.

[0098] In some implementations, the baseband processor circuitry 2122A may access a communication protocol stack 2124 in the memory / storage 2106 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 2122A may access the communication protocol stack to: perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and / or protocol data unit (PDU) layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and / or non-access stratum (NAS) layer. In some implementations, the PHY layer operations may additionally / alternatively be performed by components of the RF interface circuitry 2104. The baseband processor circuitry 2122A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some implementations, waveforms for NR may implement cyclic prefix-orthogonal frequency division multiplexing (CP-OFDM) in the UL or DL, and discrete Fourier transform-spread-orthogonal frequency division multiplexing (DFT-S-OFDM) in the UL.

[0099] The memory / storage 2106 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 2124) that can be executed by the processor 2102 to cause the UE 2100 to perform various operations described herein. The memory / storage 2106 include any type of volatile or non-volatile memory that may be distributed throughout the UE 2100. In some implementations, some of the memory / storage 2106 may be located on the processor 2102 itself (for example, Layer 1 “L1” and Layer 2 “L2” caches) , while other memory / storage 2106 is external to the processor 2102 but accessible thereto via a memory interface. The memory / storage 2106 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0100] The RF interface circuitry 2104 may include transceiver circuitry and radio frequency front end module (RFEM) that allows the UE 2100 to communicate with other devices over a radio access network. The RF interface circuitry 2104 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0101] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna (s) 2116 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor.

[0102] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna (s) 2116. In various implementations, the RF interface circuitry 2104 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0103] The antenna (s) 2116 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves over the air into electrical signals. In some implementations, the antenna elements may be arranged into one or more antenna panels. The antenna (s) 2116 may have antenna panels that are omnidirectional, directional, or a combination thereof, to enable beamforming and multiple input, multiple output communications. The antenna (s) 2116 may include any / all of microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna (s) 2116 may have one or more panels designed for one or more specific frequency bands, such as bands in frequency range 1 (FR1) or frequency range 2 (FR2) .

[0104] The user interface 2108 includes various input / output (I / O) devices designed to enable user interaction with the UE 2100. The user interface 2108 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi-character visual outputs) , or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs, ” LED displays, quantum dot displays, projectors) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 2100.

[0105] The sensors 2110 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors) ; pressure sensors; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other like audio capture devices.

[0106] The driver circuitry 2112 may include software and hardware elements that operate to control particular devices that are embedded in the UE 2100, attached to the UE 2100, or otherwise communicatively coupled with the UE 2100. The driver circuitry 2112 may include individual drivers allowing other components to interact with or control various I / O devices that may be present within, or connected to, the UE 2100. For example, driver circuitry 2112 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 2110 and control and allow access to sensors 2110, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0107] The PMIC 2114 may manage power provided to various components of the UE 2100. In particular, with respect to the processor 2102, the PMIC 2114 may control power-source selection, voltage scaling, battery charging, or direct current (DC) -to-DC conversion.

[0108] In some implementations, the PMIC 2114 may control, or otherwise be part of, various power saving mechanisms of the UE 2100. A battery 2118 may power the UE 2100, although in some examples the UE 2100 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 2118 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 2118 may be a lead-acid automotive battery.

[0109] FIG. 22 illustrates an example access node 2200 (e.g., a base station or gNB) , according to some implementations. The access node 2200 may be similar to and substantially interchangeable with base station 104. The access node 2200 may include one or more of processor 2202, RF interface circuitry 2204, core network (CN) interface circuitry 2206, memory / storage circuitry 2208, and one or more antenna (s) 2210. The processor 2202 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage circuitry 2208 to cause the access node 2200 to perform operations as described herein.

[0110] The components of the access node 2200 may be coupled with various other components over one or more interconnects 2212. The processor 2202, RF interface circuitry 2204, memory / storage circuitry 2208 (including communication protocol stack 2214) , antenna (s) 2210, and interconnects 2212 may be similar to like-named elements shown and described with respect to FIG. 13. For example, the processor 2202 may include processor circuitry such as, for example, BB processor circuitry 2216A, CPU circuitry 2216B, and GPU circuitry 2216C.

[0111] The CN interface circuitry 2206 may provide connectivity to a core network, for example, a 5G core (5GC) network using a 5GC-compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the access node 2200 via a fiber optic or wireless backhaul. The CN interface circuitry 2206 may include one or more dedicated processors or field-programmable gate arrays (FPGA) to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 2206 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0112] As used herein, the terms “access node, ” “access point, ” or the like may describe equipment that provides the radio baseband functions for data and / or voice connectivity between a network and one or more users. These access nodes can be referred to as base stations, gNBs, RAN nodes, eNBs, NodeBs, roadside units (RSU) , transmit-receive points (TRP) , and so forth, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . As used herein, the term “NG RAN node” or the like may refer to an access node 2200 that operates in an NR or 5G system (for example, a gNB) , and the term “E-UTRAN node” or the like may refer to an access node 2200 that operates in an LTE or 4G system (e.g., an eNB) . According to various implementations, the access node 2200 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0113] In some implementations, all or parts of the access node 2200 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a cloud radio access network (CRAN) and / or a virtual baseband unit pool (vBBUP) . In vehicle-to-everything (V2X) scenarios, the access node 2200 may be or act as an RSU. The term RSU refers to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU, ” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU, ” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU, ” and the like.

[0114] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to. ” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112 (f) interpretation for that component.

[0115] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, or the like, as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below.

[0116] Example 1 is a method including: receiving timing information associated with an IoT NTN TDD mode; determining an alignment between a NB-IoT frame structure and a satellite frame structure based at least on the timing information; and determining one or more subframes to monitor for downlink narrowband signals based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure.

[0117] Example 2 includes the method of example 1, where the timing information pertains to a NB-IoT TDD pattern with a periodicity of 90 ms.

[0118] Example 3 includes the method of any of examples 1 to 2, where the timing information indicates (i) a subframe offset to a first downlink subframe of the one or more subframes carrying the downlink narrowband signals and (i) a number of subframes for narrowband operation.

[0119] Example 4 includes the method of any of examples 1 to 3, where the timing information includes a bitmap, the bitmap including at least one bit that indicates an uplink or downlink subframe for NB-IoT transmission or reception.

[0120] Example 5 includes the method of any of examples 1 to 4, where the timing information includes a bitmap, the bitmap including at least one bit that indicates an uplink or downlink slot of the satellite frame structure that is associated with 8 or 7 subframes of the NB-IoT frame structure.

[0121] Example 6 includes the method of any of examples 1 to 5, where receiving the timing information includes receiving a MIB-NB or a SIB-NB including the timing information for an anchor carrier or a non-anchor carrier.

[0122] Example 7 includes the method of any of examples 1 to 6, where the one or more subframes include downlink subframes of the NB-IoT frame structure that overlap with a downlink slot of the satellite frame structure.

[0123] Example 8 includes the method of example 7, where the timing information includes an index of the downlink slot that overlaps with the downlink subframes.

[0124] Example 9 includes the method of any of examples 1 to 8, further including determining a set of subframes to use for an uplink transmission based at least on a subframe offset between the set of subframes and the one or more subframes carrying the downlink narrowband signals.

[0125] Example 10 includes the method of example 9, where the timing information includes at least one of (i) the subframe offset between the set of frames and the one or more frames or (ii) a number of frames to use for the uplink transmission.

[0126] Example 11 includes the method of any of examples 1 to 10, where the timing information includes at least one of a subframe index for an uplink transmission, a subframe index for a downlink transmission, a gap between two subframes, or an offset between an uplink subframe and a downlink subframe.

[0127] Example 12 includes the method of any of examples 1 to 11, further including: determining an association between an uplink slot and a downlink slot of the satellite frame structure; and determining the one or more subframes to monitor for the downlink narrowband signals based at least on the timing information, the satellite frame structure, and the association between the uplink slot and the downlink slot.

[0128] Example 13 includes the method of any of examples 1 to 12, where determining the alignment between the NB-IoT frame structure and the satellite frame structure includes determining a time offset between a start of the satellite frame structure and an NB-IoT TDD pattern associated with the NB-IoT frame structure.

[0129] Example 14 includes the method of any of examples 1 to 13, where determining the one or more subframes to monitor for the downlink narrowband signals includes determining at least one of a NPSS, a NPBCH, or a NSSS based at least on the timing information.

[0130] Example 15 includes the method of any of examples 1 to 14, further including determining at least one of (i) a number of downlink subframes of the NB-IoT frame structure or (ii) a number of downlink slots of the satellite frame structure to monitor for a SIB1-NB based at least on the timing information.

[0131] Example 16 includes the method of example 15, further including receiving control signaling that indicates a number of SIB1-NB repetitions configured for the IoT NTN TDD mode.

[0132] Example 17 includes the method of any of examples 15 to 16, where SIB1-NB repetitions are disabled for the IoT NTN TDD mode.

[0133] Example 18 includes the method of any of examples 15 to 17, where the SIB1-NB indicates at least one of (i) a subframe offset or (ii) a satellite slot index associated with at least one subframe allocated for an NB-IoT transmission.

[0134] Example 19 includes the method of example 18, where the SIB1-NB indicates the subframe offset relative to (i) a first downlink subframe of the one or more subframes carrying the downlink narrowband signals or (ii) an uplink slot of the satellite frame structure.

[0135] Example 20 includes the method of any of examples 18 to 19, where the at least one subframe includes an uplink subframe of the NB-IoT frame structure and the NB-IoT transmission includes a NPRACH transmission.

[0136] Example 21 includes the method of example 20, further including dropping or postponing the NPRACH transmission in response to determining that an insufficient number of subframes are available for the NPRACH transmission.

[0137] Example 22 includes the method of any of examples 1 to 21, where 7 or 8 contiguous uplink subframes of the NB-IoT frame structure are available for NTN uplink transmissions in an uplink slot of the satellite frame structure.

[0138] Example 23 is a method including: receiving scheduling information associated with an IoT NTN TDD mode; identifying one or more subframes that are available for NB-IoT communications based at least on the scheduling information; and performing the NB-IoT communications during the one or more subframes in accordance with the IoT NTN TDD mode.

[0139] Example 24 includes the method of example 23, where identifying the one or more subframes includes identifying at least one subframe that is unavailable for the NB-IoT communications based at least on an NB-IoT TDD pattern, where the one or more available subframes are indicated by a bitmap in a SIB1-NB or a MIB-NB.

[0140] Example 25 includes the method of example 24, further including delaying at least one uplink or downlink NB-IoT transmission that is scheduled during an unavailable subframe.

[0141] Example 26 includes the method of any of examples 24 to 25, where subframes carrying a NPSS, a NPBCH, a NSSS, or SIB1-NB are unavailable for the NB-IoT communications.

[0142] Example 27 includes the method of any of examples 23 to 26, further including receiving an indication of one or more NPDCCH monitoring parameters for the IoT NTN TDD mode.

[0143] Example 28 includes the method of example 27, where the one or more NPDCCH monitoring parameters indicate at least one of a maximum number of NPDCCH repetitions, an NPDCCH period, or a starting subframe of an NPDCCH search space for the IoT NTN TDD mode.

[0144] Example 29 includes the method of example 28, further including delaying or dropping an NPDCCH search space based at least on the scheduling information and the one or more NPDCCH monitoring parameters.

[0145] Example 30 includes the method of any of examples 23 to 29, further including: determining that an insufficient number of subframes are available for transmission of a system information message based at least on the scheduling information; and receiving at least a portion of the system information message transmission in subsequent available subframes.

[0146] Example 31 includes the method of any of examples 23 to 30, where system information repetitions are disabled for the IoT NTN TDD mode.

[0147] Example 32 includes the method of any of examples 23 to 31, further including receiving an indication of a system information repetition pattern for the IoT NTN TDD mode.

[0148] Example 33 includes the method of any of examples 23 to 32, further including: determining that a paging frame or a paging occasion includes an insufficient number of available downlink subframes based at least on the scheduling information; and monitoring a next available NPDCCH occasion in an available downlink subframe according to the IoT NTN TDD mode.

[0149] Example 34 includes the method of any of examples 23 to 33, further including determining an offset between a TDD structure and a H-SFN frame structure, where determining the one or more subframes is based at least on the offset.

[0150] Example 35 includes the method of example 34, further including receiving a MIB-NB or a SIB1-NB indicating the offset between the TDD structure and the H-SFN frame structure.

[0151] Example 36 is an apparatus including one or more processors configured to perform the method of any of examples 1-35.

[0152] Example 37 is a UE including: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the UE to perform the method of any of examples 1-35.

[0153] Example 38 is a method including: transmitting timing information associated with an IoT NTN TDD mode; determining an alignment between a NB-IoT frame structure and a satellite frame structure based at least on the timing information; and determining one or more subframes to use for transmission of downlink narrowband signals based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure.

[0154] Example 39 includes the method of example 38, where the timing information pertains to a NB-IoT TDD pattern with a periodicity of 90 ms.

[0155] Example 40 includes the method of any of examples 38 to 39, where the timing information indicates (i) a subframe offset to a first downlink subframe of the one or more subframes carrying the downlink narrowband signals and (i) a number of subframes for narrowband operation.

[0156] Example 41 includes the method of any of examples 38 to 40, where the timing information includes a bitmap, the bitmap including at least one bit that indicates an uplink or downlink subframe for NB-IoT transmission or reception.

[0157] Example 42 includes the method of any of examples 38 to 41, where the timing information includes a bitmap, the bitmap including at least one bit that indicates an uplink or downlink slot of the satellite frame structure that is associated with 8 or 7 subframes of the NB-IoT frame structure.

[0158] Example 43 includes the method of any of examples 38 to 42, where transmitting the timing information includes transmitting a MIB-NB or a SIB-NB including the timing information for an anchor carrier or a non-anchor carrier.

[0159] Example 44 includes the method of any of examples 38 to 43, where the one or more subframes include downlink subframes of the NB-IoT frame structure that overlap with a downlink slot of the satellite frame structure.

[0160] Example 45 includes the method of example 44, where the timing information includes an index of the downlink slot that overlaps with the downlink subframes.

[0161] Example 46 includes the method of any of examples 38 to 45, further including determining a set of subframes to use for an uplink transmission based at least on a subframe offset between the set of subframes and the one or more subframes carrying the downlink narrowband signals.

[0162] Example 47 includes the method of example 46, where the timing information includes at least one of (i) the subframe offset between the set of frames and the one or more frames or (ii) a number of frames to use for the uplink transmission.

[0163] Example 48 includes the method of any of examples 38 to 47, where the timing information includes at least one of a subframe index for an uplink transmission, a subframe index for a downlink transmission, a gap between two subframes, or an offset between an uplink subframe and a downlink subframe.

[0164] Example 49 includes the method of any of examples 38 to 48, further including: determining an association between an uplink slot and a downlink slot of the satellite frame structure; and determining the one or more subframes to use for transmission of the downlink narrowband signals based at least on the timing information, the satellite frame structure, and the association between the uplink slot and the downlink slot.

[0165] Example 50 includes the method of any of examples 38 to 49, where determining the alignment between the NB-IoT frame structure and the satellite frame structure includes determining a time offset between a start of the satellite frame structure and an NB-IoT TDD pattern associated with the NB-IoT frame structure.

[0166] Example 51 includes the method of any of examples 38 to 50, where determining the one or more subframes to use for transmission of the downlink narrowband signals includes determining at least one of a NPSS, a NPBCH, or a NSSS based at least on the timing information.

[0167] Example 52 includes the method of any of examples 38 to 51, further including determining at least one of (i) a number of downlink subframes of the NB-IoT frame structure or (ii) a number of downlink slots of the satellite frame structure to use for transmission of a SIB1-NB based at least on the timing information.

[0168] Example 53 includes the method of example 52, further including transmitting control signaling that indicates a number of SIB1-NB repetitions configured for the IoT NTN TDD mode.

[0169] Example 54 includes the method of any of examples 52 to 53, where SIB1-NB repetitions are disabled for the IoT NTN TDD mode.

[0170] Example 55 includes the method of any of examples 52 to 54, where the SIB1-NB indicates at least one of (i) a subframe offset or (ii) a satellite slot index associated with at least one subframe allocated for an NB-IoT transmission.

[0171] Example 56 includes the method of example 55, where the SIB1-NB indicates the subframe offset relative to (i) a first downlink subframe of the one or more subframes carrying the downlink narrowband signals or (ii) an uplink slot of the satellite frame structure.

[0172] Example 57 includes the method of any of examples 55 to 56, where the at least one subframe includes an uplink subframe of the NB-IoT frame structure and the NB-IoT transmission includes a NPRACH transmission.

[0173] Example 58 includes the method of example 57, further including dropping or postponing the NPRACH transmission in response to determining that an insufficient number of subframes are available for the NPRACH transmission.

[0174] Example 59 includes the method of any of examples 38 to 58, where 7 or 8 contiguous uplink subframes of the NB-IoT frame structure are available for NTN uplink transmissions in an uplink slot of the satellite frame structure.

[0175] Example 60 is a method including: transmitting scheduling information associated with an IoT NTN TDD mode; identifying one or more subframes that are available for NB-IoT communications based at least on the scheduling information; and performing the NB-IoT communications during the one or more subframes in accordance with the IoT NTN TDD mode.

[0176] Example 61 includes the method of example 60, where identifying the one or more subframes includes identifying at least one subframe that is unavailable for the NB-IoT communications based at least on an NB-IoT TDD pattern, where the one or more available subframes are indicated by a bitmap in a SIB1-NB or a MIB-NB.

[0177] Example 62 includes the method of example 61, further including delaying at least one uplink or downlink NB-IoT transmission that is scheduled during an unavailable subframe.

[0178] Example 63 includes the method of any of examples 61 to 62, where subframes carrying a NPSS, a NPBCH, a NSSS, or SIB1-NB are unavailable for the NB-IoT communications.

[0179] Example 64 includes the method of any of examples 60 to 63, further including transmitting an indication of one or more NPDCCH monitoring parameters for the IoT NTN TDD mode.

[0180] Example 65 includes the method of example 64, where the one or more NPDCCH monitoring parameters indicate at least one of a maximum number of NPDCCH repetitions, an NPDCCH period, or a starting subframe of an NPDCCH search space for the IoT NTN TDD mode.

[0181] Example 66 includes the method of example 65, further including delaying or dropping an NPDCCH search space based at least on the scheduling information and the one or more NPDCCH monitoring parameters.

[0182] Example 67 includes the method of any of examples 60 to 66, further including: determining that an insufficient number of subframes are available for transmission of a system information message based at least on the scheduling information; and transmitting at least a portion of the system information message transmission in subsequent available subframes.

[0183] Example 68 includes the method of any of examples 60 to 67, where system information repetitions are disabled for the IoT NTN TDD mode.

[0184] Example 69 includes the method of any of examples 60 to 68, further including transmitting an indication of a system information repetition pattern for the IoT NTN TDD mode.

[0185] Example 70 includes the method of any of examples 60 to 69, further including: determining that a paging frame or a paging occasion includes an insufficient number of available downlink subframes based at least on the scheduling information; and transmitting a paging message in a next available NPDCCH occasion of an available downlink subframe according to the IoT NTN TDD mode.

[0186] Example 71 includes the method of any of examples 60 to 70, further including determining an offset between a TDD structure and a H-SFN frame structure, where determining the one or more subframes is based at least on the offset.

[0187] Example 72 includes the method of example 71, further including transmitting a MIB-NB or a SIB1-NB indicating the offset between the TDD structure and the H-SFN frame structure.

[0188] Example 73 is an apparatus including one or more processors configured to perform the method of any of examples 38-72.

[0189] Example 74 is an access node including: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the access node to perform the method of any of examples 38-72.

[0190] Any of the foregoing examples can be combined with any other example (or combination of examples) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0191] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

[0192] As described above, one aspect of the present technology may relate to the gathering and use of data available from specific and legitimate sources to allow for interaction with a second device for a data transfer. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user’s health or level of fitness (e.g., vital signs measurements, medication information, exercise information) , date of birth, or any other personal information.

[0193] The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to provide for secure data transfers occurring between a first device and a second device. The personal information data may further be utilized for identifying an account associated with the user from a service provider for completing a data transfer.

[0194] The present disclosure contemplates that those entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and / or privacy practices. In particular, such entities would be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. Such information regarding the use of personal data should be prominent and easily accessible by users, and should be updated as the collection and / or use of data changes. Personal information from users should be collected for legitimate uses only. Further, such collection / sharing should occur only after receiving the consent of the users or other legitimate basis specified in applicable law. Additionally, such entities should consider taking any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices. In addition, policies and practices should be adapted for the particular types of personal information data being collected and / or accessed and adapted to applicable laws and standards, including jurisdiction-specific considerations that may serve to impose a higher standard. For example, in the US, collection of or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA) ; whereas health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0195] Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and / or software elements can be provided to prevent or block access to such personal information data. For example, the present technology can be configured to allow users to select to “opt in” or “opt out” of participation in the collection of personal information data during registration for services or anytime thereafter. For example, a user may “opt in” or “opt out” of having information associated with an account of the user stored on a user device and / or shared by the user device. In addition to providing “opt in” and “opt out” options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For example, a user may be notified upon downloading an application that their personal information data will be accessed and then reminded again just before personal information data is accessed by the application. In some instances, the user may be notified upon initiation of a data transfer of the device accessing information associated with the account of the user and / or the sharing of information associated with the account of the user with another device.

[0196] Moreover, it is the intent of the present disclosure that personal information data should be managed and handled in a way to minimize risks of unintentional or unauthorized access or use. Risk can be minimized by limiting the collection of data and deleting data once it is no longer needed. In addition, and when applicable, including in certain health related applications, data de-identification can be used to protect a user’s privacy. De-identification may be facilitated, when appropriate, by removing identifiers, controlling the amount or specificity of data stored (e.g., collecting location data at city level rather than at an address level) , controlling how data is stored (e.g., aggregating data across users) , and / or other methods such as differential privacy.

[0197] Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal information data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal information data. For example, content can be selected and delivered to users based on aggregated non-personal information data or a bare minimum amount of personal information, such as the content being handled only on the user’s device or other non-personal information available to the content delivery services.

Claims

1.A method comprising:receiving timing information associated with an Internet-of-Things (IoT) non-terrestrial network (NTN) time-division duplexing (TDD) mode;determining an alignment between a narrowband IoT (NB-IoT) frame structure and a satellite frame structure based at least on the timing information; anddetermining one or more subframes to monitor for downlink narrowband signals based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure.2.The method of claim 1, wherein the timing information pertains to a NB-IoT TDD pattern with a periodicity of 90 milliseconds (ms) .3.The method of claim 1, wherein the timing information indicates (i) a subframe offset to a first downlink subframe of the one or more subframes carrying the downlink narrowband signals and (i) a number of subframes for narrowband operation.4.The method of claim 1, wherein the timing information comprises a bitmap, the bitmap comprising at least one bit that indicates an uplink or downlink subframe for NB-IoT transmission or reception.5.The method of claim 1, wherein the timing information comprises a bitmap, the bitmap comprising at least one bit that indicates an uplink or downlink slot of the satellite frame structure that is associated with 8 or 7 subframes of the NB-IoT frame structure.6.The method of claim 1, wherein receiving the timing information comprises receiving a narrowband master information block (MIB-NB) or a narrowband system information block (SIB-NB) comprising the timing information for an anchor carrier or a non-anchor carrier.7.The method of claim 1, wherein the one or more subframes comprise downlink subframes of the NB-IoT frame structure that overlap with a downlink slot of the satellite frame structure.8.The method of claim 1, further comprising determining a set of subframes to use for an uplink transmission based at least on a subframe offset between the set of subframes and the one or more subframes carrying the downlink narrowband signals.9.The method of claim 8, wherein the timing information comprises at least one of (i) the subframe offset between the set of frames and the one or more frames or (ii) a number of frames to use for the uplink transmission.10.A method comprising:receiving scheduling information associated with an Internet-of-Things (IoT) non-terrestrial network (NTN) time-division duplexing (TDD) mode;identifying one or more subframes that are available for narrowband IoT (NB-IoT) communications based at least on the scheduling information; andperforming the NB-IoT communications during the one or more subframes in accordance with the IoT NTN TDD mode.11.The method of claim 10, wherein identifying the one or more subframes comprises identifying at least one subframe that is unavailable for the NB-IoT communications based at least on an NB-IoT TDD pattern, wherein the one or more available subframes are indicated by a bitmap in a narrowband system information block 1 (SIB1-NB) or a narrowband master information block (MIB-NB) .12.The method of claim 11, further comprising delaying at least one uplink or downlink NB-IoT transmission that is scheduled during an unavailable subframe.13.The method of claim 11, wherein subframes carrying a narrowband primary synchronization signal (NPSS) , a narrowband physical broadcast channel (NPBCH) , a narrowband secondary synchronization signal (NSSS) , or narrowband system information block 1 (SIB1-NB) are unavailable for the NB-IoT communications.14.The method of claim 10, further comprising receiving an indication of one or more narrowband physical downlink control channel (NPDCCH) monitoring parameters for the IoT NTN TDD mode.15.The method of claim 14, wherein the one or more NPDCCH monitoring parameters indicate at least one of a maximum number of NPDCCH repetitions, an NPDCCH period, or a starting subframe of an NPDCCH search space for the IoT NTN TDD mode.16.The method of claim 15, further comprising delaying or dropping an NPDCCH search space based at least on the scheduling information and the one or more NPDCCH monitoring parameters.17.An apparatus comprising one or more processors configured to perform the method of any of claims 1-16.18.A user equipment (UE) comprising:one or more processors; andmemory storing instructions that, when executed by the one or more processors, cause the UE to perform the method of any of claims 1-16.19.A method comprising:transmitting timing information associated with an Internet-of-Things (IoT) non-terrestrial network (NTN) time-division duplexing (TDD) mode;determining an alignment between a narrowband IoT (NB-IoT) frame structure and a satellite frame structure based at least on the timing information; anddetermining one or more subframes to use for transmission of downlink narrowband signals based at least on the determined alignment between the NB-IoT frame structure and the satellite frame structure.20.A method comprising:transmitting scheduling information associated with an Internet-of-Things (IoT) non-terrestrial network (NTN) time-division duplexing (TDD) mode;identifying one or more subframes that are available for narrowband IoT (NB-IoT) communications based at least on the scheduling information; andperforming the NB-IoT communications during the one or more subframes in accordance with the IoT NTN TDD mode.21.An apparatus comprising one or more processors configured to perform the method of any of claims 19-20.22.An access node comprising:one or more processors; andmemory storing instructions that, when executed by the one or more processors, cause the access node to perform the method of any of claims 19-20.

Images