Proximity distance design for redcap UE in ntn

WO2026165728A1PCT designated stage Publication Date: 2026-08-13APPLE INC
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-02-05
Publication Date
2026-08-13

Smart Images

  • Figure CN2025075854_13082026_PF_FP_ABST
    Figure CN2025075854_13082026_PF_FP_ABST
Patent Text Reader

Abstract

An apparatus configured to process, based on non-terrestrial network (NTN) signaling, synchronization signal block (SSB) -based measurement timing configuration (SMTC) configuration information comprising at least a first SMTC occasion and a second SMTC occasion and, when there is a collision between the first SMTC occasion and the second SMTC occasion based on a proximity distance associated with a reduced capability (redcap) user equipment (UE), select one of the first SMTC occasion and the second SMTC occasion to use for mobility measurements.
Need to check novelty before this filing date? Find Prior Art

Description

Proximity Distance Design for Redcap UE in NTNBACKGROUND

[0001] A user equipment (UE) may establish a connection to at least one of multiple different networks or types of networks. For example, the UE may use a non-terrestrial network (NTN) to access a radio access network (RAN) and public land mobile network (PLMN) . The term NTN refers to a network utilizing non-terrestrial components (e.g., one or more satellites) for network access.

[0002] A synchronization signal block (SSB) -based measurement timing configuration (SMTC) may include multiple SMTC occasions during which the UE may perform mobility measurements. A proximity distance between a first SMTC occasion and a second SMTC occasion relates to a UE’s capability for processing data collected during an SMTC occasion. When the proximity distance between the first SMTC occasion and the second SMTC occasion is less than a predetermined duration of time, the UE may decide to only process one of the first SMTC occasion or the second SMTC occasion due to the UE’s processing capabilities.

[0003] The NTN may support reduced capability (redcap) UEs. Typically, redcap UEs have lesser processing capabilities than non-redcap UEs and thus, the proximity distance design for non-redcap UEs in the NTN may not be appropriate for redcap UEs in the NTN. Accordingly, there is a need for a proximity distance design for redcap UEs in the NTN.SUMMARY

[0004] Some example embodiments are related to an apparatus having memory coupled to processing circuitry, the processing circuitry configured to process, based on non-terrestrial network (NTN) signaling, synchronization signal block (SSB) -based measurement timing configuration (SMTC) configuration information comprising at least a first SMTC occasion and a second SMTC occasion and when there is a collision between the first SMTC occasion and the second SMTC occasion based on a proximity distance associated with a reduced capability (redcap) user equipment (UE) , select one of the first SMTC occasion and the second SMTC occasion to use for mobility measurements.

[0005] Other example embodiments are related to a method for processing, based on non-terrestrial network (NTN) signaling, synchronization signal block (SSB) -based measurement timing configuration (SMTC) configuration information comprising at least a first SMTC occasion and a second SMTC occasion and when there is a collision between the first SMTC occasion and the second SMTC occasion based on a proximity distance associated with a reduced capability (redcap) user equipment (UE) , selecting one of the first SMTC occasion and the second SMTC occasion to use for mobility measurements.Brief Description of the Drawings

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

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

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

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

[0010] Fig. 5 shows an example of a proximity distances according to various example embodiments.

[0011] Fig. 6 shows a method for a synchronization signal block (SSB) measurement timing configuration (SMTC) occasion collision handling for redcap UEs in an NTN according to various example embodiments.Detailed Description

[0012] The example embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The example embodiments relate to a synchronization signal block (SSB) measurement timing configuration (SMTC) for reduced capability (redcap) user equipments (UEs) in a non-terrestrial network (NTN) .

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

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

[0015] In addition, the example embodiments are described with regard to a redcap UE. Redcap UEs may be configured with complexity reduction features such as, but not limited to, a lower maximum bandwidth compared to non-redcap UEs, a reduced number of antenna branches compared to non-redcap UEs, relaxed processing time compared to non-redcap UEs and relaxed processing capability compared to non-redcap UEs. These features may provide cost and / or complexity reduction benefits. However, any reference to a redcap UE having a particular complexity reduction feature is merely provided for illustrative purposes. There may be different redcap device types and different networks may define redcap UEs using different complexity reduction features.

[0016] Throughout this description, the terms “UE, ” “redcap device” and “redcap UE” may be used interchangeably to represent any electronic component that may establish a connection to a network and is equipped with capabilities that may be characterized as 3GPP redcap capabilities. Further, the terms “non-redcap device, ” “non-redcap UE” and “legacy UE” may be used interchangeably to represent any type of UE excluding UEs equipped with capabilities that may be characterized as 3GPP redcap capabilities.

[0017] The example embodiments are further described with regard to SMTC. Generally, SMTC refers to a configuration for mobility measurements. SMTC may include multiple SMTC occasions during which the UE may perform mobility measurements. A proximity distance between a first SMTC occasion and a second SMTC occasion relates to a UE’s capability for processing data collected during an SMTC occasion. When the proximity distance between the first SMTC occasion and the second SMTC occasion is less than a threshold, the UE may determine to only process one of the first SMTC occasion or the second SMTC occasion due to the UE’s processing capabilities.

[0018] The example embodiments introduce an SMTC proximity distance design for redcap UEs in an NTN. The example embodiments may be used independently from one another, in conjunction with currently implemented SMTC features for redcap UEs, in conjunction with future implementations of SMTC features for redcap UEs or independently from other SMTC features for redcap UEs.

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

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

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

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

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

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

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

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

[0027] The processor 205 may be configured to execute a plurality of engines of the UE 110. For example, the engines may include a SMTC engine 235. The SMTC engine 235 may perform various operations related to the example embodiments introduced herein. For example, the SMTC engine 235 may perform operations such as, but not limited to, receiving SMTC configuration information, collecting measurement data during an SMTC occasion, determining a proximity distance between SMTC occasions and determining whether to collect measurement data during a first SMTC occasion or a second SMTC occasion based on the proximity distance. These and other operations are described in greater detail below.

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

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

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

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

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

[0033] The processor 305 may be configured to execute a plurality of engines for the base station 300. For example, the engines may include a SMTC engine 330. The SMTC engine 330 may perform various operations related to implementing SMTC in an NTN for redcap UEs.

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

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

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

[0037] Fig. 4 shows an example non-terrestrial network (NTN) architecture 400 according to various example embodiments. An NTN may relate to any network using non-terrestrial components, such as satellites, airplanes, High Altitude Platform Systems (HAPS) , etc., to provide network services to a UE.

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

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

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

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

[0042] Fig. 5 shows an example 500 of a proximity distances according to various example embodiments. The example 500 includes SMTC occasions 510-512. During the SMTC occasions 510-512 there may be bursts of reference signals (e.g., SSBs, etc. ) and the UE 110 may collect measurement data based on the reference signals. However, reference to the term SMTC occasion is not intended to limit the example embodiments. Different entities may refer to a similar concept by a different name (e.g., SMTC window, etc. ) .

[0043] In this example, a proximity distance 530 is illustrated between SMTC occasion 510 and SMTC occasion 512. The proximity distance 530 may represent the time difference  between the ending point of earlier SMTC occasion 510 and the starting point of the later SMTC occasion 512. The proximity distance relates to the processing capability of the UE 110 for the data collected during an SMTC occasion. In some examples, a collision between SMTC occasions may be declared when the proximity distance is less than or equal to a predetermined value. When there is a collision between two SMTC occasions, the UE 110 may determine to collect measurement data from only one of the SMTC occasions.

[0044] In this example, an SMTC periodicity 540 is also illustrated. The SMTC periodicity represents a time period during which one or more SMTC occasions are scheduled. In this example, the SMTC periodicity 540 includes two SMTC occasions 510-512 and when the SMTC periodicity 540 ends, the SMTC occasions 510-512 are repeated. However, this is only one example configuration of SMTC periodicity and an actual SMTC periodicity may be any appropriate duration and may include any number of SMTC occasions.

[0045] Each SMTC occasion may al so be associated with an SMTC time offset that is defined relative to the SMTC periodicity. In this example, SMTC occasion 510 may have an SMTC time offset 550 with a parameter value of 0 because SMTC occasion 510 starts at the beginning of the SMTC periodicity 540. SMTC occasion 512 may have an SMTC offset 555 with parameter value of (M) . However, this is only one example configuration of SMTC time offsets and an actual SMTC time offset may be any appropriate value.

[0046] Fig. 6 shows a method 600 for SMTC occasion collision handling for redcap UEs in an NTN according to various example embodiments. The method 600 is described from the perspective of the UE 110 and provides a general overview of SMTC occasion collision handling. Specific aspects of SMTC proximity distance design for redcap UEs in an NTN with be described in more detail below after the method 600.

[0047] In 610, the UE 110 receives SMTC configuration information. The SMTC configuration information may be provided in one or more radio resource control (RRC) messages or in any other appropriate manner. The SMTC configuration information may include parameters for aspects of SMTC such as, but not limited to, SMTC occasions, SMTC periodicity and SMTC time offsets.

[0048] In 620, the UE 110 determines that there is a collision between a first SMTC occasion and a second SMTC occasion. In some examples, the UE 110 may determine that there is an SMTC collision based, at least in part, on the proximity distance between the first SMTC occasion and the second SMTC occasion and a threshold.

[0049] In 630, the UE 110 selects one of the SMTC occasions to use for collecting measurement data in response to the collision. In 640, the UE 110 collects measurement data during the selected SMTC occasion. For example, the UE 110 may select the first SMTC occasion and thus, the UE 110 may collect measurement data during the first SMTC occasion and may omit collecting measurement data during the second SMTC occasion.

[0050] According to some aspects, the proximity distance design for redcap UEs in an NTN may not consider the capability SMTC number of the NTN carrier. In one approach, the example embodiments introduce an extended proximity distance threshold for redcap UEs in an NTN. With this approach, a collision between two SMTC occasions outside of a measurement gap may be considered to have occurred if the two SMTC occasions are fully or partially overlapping in the time domain. In addition, a collision between two SMTC occasions outside of a measurement gap may be considered to have occurred if the magnitude of the distance between the two SMTC occasions in the time domain (e.g., proximity distance) is less than or equal to (4+X) milliseconds (ms) where X is greater than 0 (e.g., extended proximity distance threshold) . As described above with regard to the example 400 of Fig. 4, the proximity distance between two SMTC occasions may be defined as the time difference between the ending point of the earlier SMTC occasion and the starting point of the later SMTC occasion. In some example embodiments, the extended proximity distance threshold may be used when the UE 110 is configured with more than one SMTC on a satellite access node (SAN) carrier. However, this condition is not required, and the extended proximity distance threshold may be used in any appropriate scenario.

[0051] The X parameter may be configured in a variety of different ways. In some example embodiments, the X parameter may be a fixed value. To provide some non-limiting examples, the X parameter may be . 1 ms, . 2 ms, . 25 ms, . 5 ms, . 75 ms, 1 ms, 1.25 ms, 1.5 ms, 1.75 ms or 2 ms. In some examples, there may be a different X value for frequency rage 1 (FR1

[0052] ) and frequency range 2 (FR2) . For example, the X value may be . 25 ms for FR2 and . 5 ms for FR1 to account for the different characteristics of these FRs.

[0053] In other example embodiments, the X parameter may be a value related to the redcap UE capability. For example, a first X value may be defined for redcap UEs with 1 receive (RX) antenna branch and a second different X value for redcap UEs with 2 RX antenna branches. In other example embodiments, the value of X may be band specific, carrier specific or UE specific.

[0054] In some example embodiments, the network may indicate a value for the proximity distances threshold to the UE 110. In other examples, the network may indicate a value for the X to the UE 110. This information may be provided to the UE 110 in the SMTC configuration information or in any other appropriate manner.

[0055] The UE 110 may indicate to the network a proximity distance threshold that the UE 110 is to use to declare a collision between SMTC occasions. In some example embodiments, a new capability for redcap UEs is introduced to indicate a proximity distance requirement for SMTC in an NTN to the network. The network may generate the SMTC for the UE 110 based on the information provided by the UE 110 and attempt to avoid configuring the UE 110 with SMTC occasions that have a proximity distance that is less than and / or equal to the proximity distance threshold.

[0056] To provide an example, the UE 110 may send a message to the network indicating that the extended proximity distance threshold is to be used (e.g., 4 ms + X) . The message may include a binary indication indicating whether the extended proximity distance threshold is to be used or whether the proximity distance threshold for non-redcap UEs in an NTN is to be used (e.g., 4 ms) . In other examples, the message may explicitly or implicitly identify a specific value to be used for the proximity distance threshold that is not less than 4 ms. In further examples, the capability may be band specific, FR specific, carrier specific or UE specific. The message may be capability information or any other appropriate type of message.

[0057] In some example embodiments, the message may indicate multiple proximity distance thresholds. For example, a first proximity distance threshold may be indicated for FR1 and a second different proximity distance threshold may be indicated for FR2. In other example embodiments, different proximity distance thresholds may be indicated for different bands or carriers.

[0058] In some example embodiments, the UE 110 may indicate the proximity distance threshold before the network configures SMTC for the UE 110. In other example embodiments, the UE 110 may indicate the proximity distance threshold after the network configures SMTC for the UE 110.

[0059] In another approach, the proximity distance threshold may be based on the SMTC occasion size. A smaller SMTC occasion size may require a smaller proximity distance because there is less data to process. With this approach, a predefined scale may be used where the magnitude of the proximity distance threshold correlates to the SMTC occasion size. For example, a first proximity distance size may be used for a first set of one or more SMTC occasion sizes and a second, larger, proximity distance size may be used for a second set of one or more SMTC occasions sizes that are larger than the first set of SMTC occasion sizes. This predefined scale may be hard encoded in 3GGP standards or provided to the UE 110 in any other appropriate manner. The UE 110 and the network may communicate to enlarge or reduce the proximity distance thresholds based on the scale.

[0060] In addition to or alternatively, the UE 110 may indicate the proximity distance threshold the UE 110 is to use after the network configures the SMTC occasion size. For example, when the network configures the UE 110 with a first SMTC occasion size, the UE 110 may indicate to the network that it is to use a first proximity distance threshold. When the network configures the UE 110 with a second SMTC occasion size that is smaller than the first SMTC occasion size, the UE 110 may indicate to the network that a second proximity distance threshold that is smaller than the first proximity distance threshold is to be used by the UE 110.

[0061] In another approach, the proximity distance may be based on SMTC periodicity. A smaller SMTC periodicity may limit the time interval between SMTC occasions within the same SMTC periodicity and thus, the UE 110 may need to use a shorter proximity distance threshold to support multiple SMTC occasions in the same SMTC periodicity. With this approach, a predefined scale may be used where the magnitude of the proximity distance threshold correlates to the SMTC periodicity. For example, a first proximity distance size may be used for a SMTC periodicity and a second, larger, proximity distance size may be used for a second SMTC periodicity that is larger than the first SMTC periodicity. This predefined scale may be hard encoded in 3GGP standards or provided to the UE 110 in any other appropriate manner. The UE 110 and the network may communicate to enlarge or reduce the proximity distance threshold based on the scale.

[0062] Alternatively, the UE 110 may indicate the proximity distance threshold the UE 110 is to use after the network configures the SMTC periodicity. For example, when the network configures the UE 110 with a first SMTC periodicity, the UE 110 may indicate to the network that it is to use a first proximity distance threshold. When the network configures the UE 110 with a second SMTC periodicity that is smaller than the first SMTC periodicity, the UE 110 may indicate to the network that a second proximity distance threshold that is smaller than the first proximity distance threshold is to be used by the UE 110.

[0063] According to some aspects, the proximity distance design for redcap UEs in an NTN may consider the capability SMTC number of the NTN carrier. In one approach, the proximity distance threshold may be based on a number of SMTC occasions supported by the UE 110 on an NTN carrier. For example, when the UE 110 is configured with more than one SMTC on a SAN carrier, a collision between two SMTC occasion outside a measurement gap may be considered to have occurred if two SMTC occasions are fully or partially overlapping in the time domain. In addition, a collision between two SMTC occasions outside of a measurement gap may be considered to have occurred if the magnitude of the distance between the two SMTC occasions in the time domain (e.g., proximity distance) is less than or equal to Y ms (e.g., the proximity distance threshold) . If the UE 110 supports 2 SMTCs on a SAN carrier, Y may be equal to a first value (Y1) . If the UE 110 supports 3 SMTCs on a SAN carrier, Y may be equal to a first value (Y2) . I f the UE 110 supports 4 SMTCs on a SAN carrier, Y may be equal to a third value (Y3) . However, support of 4 SMTC on a SAN carrier is merely provided for illustrative purposes. Those skilled in the art will understand how the example embodiments may be used if the UE 110 supports more than 4 SMTCs.

[0064] In some example embodiments, a predefined scale may be used to determine Y. The predefined scale may be hard encoded in 3GPP Technical Specifications or provided to the UE 110 in any other appropriate manner. For example, within a same SMTC periodicity, when the SMTC number is increased the value of Y will decrease (e.g., Y1 > Y2 > Y3) . In another example, within a same SMTC periodicity, when the SMTC number is increased the value of Y will decrease (e.g., Y1 < Y2 < Y3) .

[0065] In some example embodiments, the UE 110 may send a message to the networking indicating support for a number of SMTCs associated with a particular proximity distance. The UE 110 may indicate parallel measurements on multiple SMTC for a single carrier frequency, a supported SMTC number associated with different Y values, a largest Y value and / or a smallest Y value. The indication may be provided to the network as capability information or sent to the network in any other appropriate manner.

[0066] For example, the UE 110 may send a message to the network indicating support for up to 3 SMCTs. The UE 110 may further indication that for 3 SMTCs the proximity distance threshold is a first value (Y2) and for 2 SMTCs the proximity distance threshold is a second value (Y3) . In another example, the UE 110 may indicate support for up to 4 SMTCs. The UE 110 may further indicate that a maximum value (e.g., max {Y1, Y2, Y3}) or a minimum value (e.g., min {Y1, Y2, Y3} ) for the proximity distance threshold.

[0067] In some example embodiments, the UE 110 may send a message to the network indicating support of a proximity distance associated with the supported SMTC number on the NTN carrier. For example, the UE 110 may indicate a specific value (e.g., (Y1, Y2, Y3) ) to the network as the supported proximity distance for each SMTC number supported by the UE 110. In another example, the UE 110 may indicate an upper bound, e.g., Y3 for UE 110 to support up to 4 SMTCs.

[0068] In some example embodiments, the proximity distance threshold may be based on number of supported SMTCs. With this approach, a predefined scale may be used where the magnitude of the proximity distance threshold correlates to the number of supported SMTCs. For example, a first proximity distance size may be used for a first number of supported SMTCs and a second, larger, proximity distance size may be used for a second number of supported SMTCs that are larger than the first number of supported SMTCs. This predefined scale may be hard encoded in 3GGP standards or provided to the UE 110 in any other appropriate manner. The UE 110 and the network may communicate to enlarge or reduce the proximity distance thresholds based on the scale.

[0069] In another approach, the proximity distance may be based on SMTC periodicity. A smaller SMTC periodicity may limit the time interval between SMTC occasions within the same SMTC periodicity and thus, the UE 110 may need to use a shorter proximity distance threshold. With this approach, a predefined scale may be used where the magnitude of the proximity distance threshold correlates to the SMTC periodicity. For example, a first proximity distance size may be used for a first SMTC periodicity and a second, larger, proximity distance size may be used for a second SMTC periodicity that is larger than the first SMTC periodicity. This predefined scale may be hard encoded in 3GPP TS or provided to the UE 110 in any other appropriate manner. The UE 110 and the network may communicate to enlarge or reduce the proximity distance threshold based on the scale.

[0070] For each of the examples provided above, the UE 110 may indicate the supported proximity distance to the network before or after the SMTC has been configured.Examples

[0071] In a first example, a method, comprising processing, based on non-terrestrial network (NTN) signaling, synchronization signal block (SSB) -based measurement timing configuration (SMTC) configuration information comprising at least a first SMTC occasion and a second SMTC occasion and, when there is a collision between the first SMTC occasion and the second SMTC occasion based on a proximity distance associated with a reduced capability (redcap) user equipment (UE) , selecting one of the first SMTC occasion and the second SMTC occasion to use for mobility measurements.

[0072] In a second example, the method of the first example, further comprising determining whether there is the collision between the first SMTC occasion and the second SMTC occasion based on comparing the proximity distance to a proximity distance threshold, wherein the proximity distance threshold is equal to 4 milliseconds (ms) plus a parameter (X) .

[0073] In a third example, the method of the second example, wherein the parameter (X) is a fixed value.

[0074] In a fourth example, the method of the second example, wherein the parameter X is a first value for frequency range 1 (FR1) and a second value for frequency range 2 (FR2) , wherein the second value is greater than the first value.

[0075] In a fifth example, the method of the second example, wherein a value for the parameter X is based on a number of receive (RX) antenna branches of the redcap UE.

[0076] In a sixth example, the method of the second example, further comprising processing, based on signaling received from the NTN, a value for the parameter X.

[0077] In a seventh example, the method of the first example, further comprising processing, based on signaling received from the NTN, a value for a proximity distance threshold that is to be compared to the proximity distance.

[0078] In an eighth example, the method of the first example, further comprising generating, for transmission to the NTN, an indication of a proximity distance threshold to be used to determine whether there is the collision between the first SMTC occasion and the second SMTC occasion.

[0079] In a ninth example, the method of the eighth example, wherein the indication is a binary indication configured to indicate whether a first proximity distance threshold for non-redcap UEs is to be used by the redcap UE or whether an extended proximity distance threshold for redcap UEs is to be used by the redcap UE.

[0080] In a tenth example, the method of the eighth example, wherein the indication is a value for the proximity distance threshold that is equal to or greater than 4 milliseconds (ms) .

[0081] In an eleventh example, the method of the eighth example, wherein the proximity distance threshold is band specific, frequency range (FR) specific, carrier specific or UE specific.

[0082] In a twelfth example, the method of the eighth example, wherein the indication is provided to the NTN after the NTN configuration information.

[0083] In a thirteenth example, the method of the first example, wherein the proximity distance is based on an SMTC occasion size.

[0084] In a fourteenth example, the method of the thirteenth example, wherein the proximity distance is increased after the network configures the SMTC occasion size using a predefined scale.

[0085] In a fifteenth example, the method of the first example, wherein the proximity distance is based on an SMTC periodicity.

[0086] In a sixteenth example, the method of the fifteenth example, wherein the proximity distance is decreased after the network configures the SMTC periodicity using a predefined scale.

[0087] In a seventeenth example, the method of the first example, further comprising determining whether there is the collision between the first SMTC occasion and the second SMTC occasion based on comparing the proximity distance to a proximity distance threshold, wherein the proximity distance threshold is equal to a parameter (Y) .

[0088] In an eighteenth example, the method of the seventeenth example, wherein a value for the parameter Y is based on a number of SMTCs per carrier supported by the redcap UE.

[0089] In a nineteenth example, the method of the eighteenth example, wherein the value for the parameter Y is equal to a first value when the UE supports 2 SMTCs on a satellite access node (SAN) of the NTN, the parameter Y is equal to a second value when the UE supports 3 SMTCs on the SAN of the NTN and the parameter Y is equal to a third value when the UE supports 4 SMTCs on the SAN of the NTN.

[0090] In a twentieth example, the method of the nineteenth example, wherein within a same SMTC periodicity, the first value is greater than the second value and the second value is greater than the third value.

[0091] In a twenty first example, the method of the nineteenth example, wherein within a same SMTC periodicity, the first value is less than the second value and the second value is less than the third value.

[0092] In a twenty second example, the method of the first example, further comprising generating, for transmission to the NTN, an indication of a first number of SMTCs supported by the redcap UE associated with a first proximity distance threshold value and a second number of SMTCs support by the redcap UE associated with a second proximity distance threshold value.

[0093] In a twenty third example, the method of the first example, further comprising generating, for transmission to the NTN, an indication of a number of supported SMTCs by the redcap UE and at least one of a maximum proximity distance threshold value and a minimum proximity distance threshold value.

[0094] In a twenty fourth example, the method of the first example, wherein the proximity distance is based at least one of a number of supported SMTCs per carrier by the redcap UE and an SMTC periodicity.

[0095] In a twenty fifth example, the method of the twenty fourth example, wherein the proximity distance is increased or decreased after the network configures the SMTC periodicity using a predefined scale.

[0096] In a twenty sixth example, the method of the first example, further comprising generating, for transmission to the NTN, a value for the proximity distance corresponding to a number of supported SMTCs by the redcap UE.

[0097] In a twenty seventh example, the method of the twenty sixth example, wherein the value for the proximity distance corresponding to the number of supported SMTCs by the redcap UE is provided to the NTN after the SMTC configuration information.

[0098] In a twenty eighth example, the method of the twenty sixth example, wherein the value for the proximity distance corresponding to the number of supported SMTCs by the redcap UE is provided to the NTN before the SMTC configuration information.

[0099] In a twenty ninth example, one or more processors configured to perform any of the methods of the first through twenty eighth examples.

[0100] In a thirtieth example, a reduced capability (redcap) user equipment (UE) configured to perform any of the methods of the first through twenty eighth examples.

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

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

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

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

Claims

1.An apparatus comprising memory coupled to processing circuitry, the processing circuitry configured to:process, based on non-terrestrial network (NTN) signaling, synchronization signal block (SSB) -based measurement timing configuration (SMTC) configuration information comprising at least a first SMTC occasion and a second SMTC occasion; andwhen there is a collision between the first SMTC occasion and the second SMTC occasion based on a proximity distance associated with a reduced capability (redcap) user equipment (UE) , select one of the first SMTC occasion and the second SMTC occasion to use for mobility measurements.2.The apparatus of claim 1, wherein the processing circuitry is configured to determine whether there is the collision between the first SMTC occasion and the second SMTC occasion based on comparing the proximity distance to a proximity distance threshold, wherein the proximity distance threshold is equal to 4 milliseconds (ms) plus a parameter (X) .3.The apparatus of claim 2, wherein the parameter (X) is a fixed value.4.The apparatus of claim 2, wherein the parameter X is a first value for frequency range 1 (FR1) and a second value for frequency range 2 (FR2) , wherein the second value is greater than the first value.5.The apparatus of claim 2, wherein a value for the parameter X is based on a number of receive (RX) antenna branches of the redcap UE.6.The apparatus of claim 2, wherein the processing circuitry is further configured to:process, based on signaling received from the NTN, a value for the parameter X.7.The apparatus of claim 1, wherein the processing circuitry is further configured to:process, based on signaling received from the NTN, a value for a proximity distance threshold that is to be compared to the proximity distance.8.The apparatus of claim 1, wherein the processing circuitry is further configured to:generate, for transmission to the NTN, an indication of a proximity distance threshold to be used to determine whether there is the collision between the first SMTC occasion and the second SMTC occasion.9.The apparatus of claim 1, wherein the proximity distance is based on an SMTC occasion size.10.The apparatus of claim 1, wherein the proximity distance is based on an SMTC periodicity.11.The apparatus of claim 1, wherein the processing circuitry is configured to determine whether there is the collision between the first SMTC occasion and the second SMTC occasion based on comparing the proximity distance to a proximity distance threshold, wherein the proximity distance threshold is equal to a parameter (Y) .12.The apparatus of claim 11, wherein a value for the parameter Y is based on a number of SMTCs per carrier supported by the redcap UE.13.The apparatus of claim 12, wherein the value for the parameter Y is equal to a first value when the UE supports 2 SMTCs on a satellite access node (SAN) of the NTN, the parameter Y is equal to a second value when the UE supports 3 SMTCs on the SAN of the NTN and the parameter Y is equal to a third value when the UE supports 4 SMTCs on the SAN of the NTN.14.The apparatus of claim 1, wherein the processing circuitry is further configured to:generate, for transmission to the NTN, an indication of a first number of SMTCs supported by the redcap UE associated with a first proximity distance threshold value and a second number of SMTCs support by the redcap UE associated with a second proximity distance threshold value.15.The apparatus of claim 1, wherein the processing circuitry is further configured to:generate, for transmission to the NTN, an indication of a number of supported SMTCs by the redcap UE and at least one of a maximum proximity distance threshold value and a minimum proximity distance threshold value.16.The apparatus of claim 1, wherein the proximity distance is based at least one of a number of supported SMTCs per carrier by the redcap UE and an SMTC periodicity.17.The apparatus of claim 16, wherein the proximity distance is increased or decreased after the network configures the SMTC periodicity using a predefined scale.18.The apparatus of claim 1, wherein the processing circuitry is further configured to:generate, for transmission to the NTN, a value for the proximity distance corresponding to a number of supported SMTCs by the redcap UE.19.The apparatus of claim 18, wherein the value for the proximity distance corresponding to the number of supported SMTCs by the redcap UE is provided to the NTN after the SMTC configuration information.20.The apparatus of claim 18, wherein the value for the proximity distance corresponding to the number of supported SMTCs by the redcap UE is provided to the NTN before the SMTC configuration information.