EP4643473A1

EP4643473A1 - Managing non-access stratum signaling connection and discontinous coverage using a timer for accessing a non-terrestrial network

Info

Publication number: EP4643473A1
Application number: EP24711041.4A
Authority: EP
Inventors: Sang Min Park; Chih-Hsiang Wu
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-02-06
Filing date: 2024-02-05
Publication date: 2025-11-05
Also published as: WO2024167827A1; CN120693804A; EP4643474A1; WO2024167825A1

Abstract

A core network device (110) communicating with a user equipment (102) via a non-terrestrial network (105) performs a method (1600) for managing network signaling during discontinuous coverage. The method includes: (i) receiving (1602) from the user equipment via the non-terrestrial network, an uplink message, and (ii) transmitting (1604), to the UE via the NTN and responsive to the receiving of the uplink message, a downlink message including a timer indication corresponding to an out‑of‑NTN‑coverage period of the user equipment.

Description

MANAGING NON-ACCESS STRATUM SIGNALING CONNECTION AND DISCONTINOUS COVERAGE USING A TIMER FOR ACCESSING A NONTERRESTRIAL NETWORK

FIELD OF THE DISCLOSURE

[0001] This document relates generally to methods and devices operating in wireless communication systems, such as (but not limited to) communication systems described in Third Generation Partnership (3GPP) technical specifications. More specifically, the method and system manage non-access stratum (NAS) signaling connection and discontinuous coverage of a user equipment (UE) connected to the core network via a non-terrestrial network (NTN).

BACKGROUND

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

[0003] The fifth generation (5G) technology relies primarily on legacy terrestrial networks. However, the 3GPP organization has proposed to extend 5G communications to non-terrestrial networks (NTNs) with 5G new radio (NR) technologies, or with the Long-Term-Evolution (LTE) technologies tailored for the Narrowband Internet-of-Thing (NB-loT) or the enhanced Machine Type Communication (eMTC) scenarios. In an NTN, an RF transceiver is mounted on a satellite, an uncrewed aircraft system (UAS) also referred to as drone, balloon, plane, or another suitable apparatus. For simplicity, the discussion below refers to all such apparatus as satellites. In addition to satellites, an NTN includes one or more satellite gateways (sat-gateways) that connect the NTN to a public data network, feeder links between sat- gateways and satellites, service links between satellites, and inter-satellite links (ISL) when satellites form constellations.

[0004] A satellite can belong to one of several types based on altitude, orbit, and beam footprint size. The types include Low-Earth Orbit (LEO) satellite, Medium-Earth Orbit (MEO) satellite, Geostationary Earth Orbit (GEO) satellite, UAS platform (including High Altitude Platform Station (HAPS)), and High Elliptical Orbit (HEO) satellite. GEO satellites are also known as the Geosynchronous Orbit (GSO) satellites, and LEO/MEO satellites are also known as non-GSO (NGSO) satellites.

[0005] A GSO satellite can communicate with one or more sat-gateways deployed over a satellite targeted coverage area (e.g., a region, country, continent, etc.). A non- GSO satellite at different times can communicate with one or several serving sat- gateways. An NTN is designed to ensure service and feeder link continuity between successive serving sat-gateways, with sufficient time duration to proceed with mobility anchoring and hand-over procedures.

[0006] A satellite can support a transparent or a regenerative (with on board processing) payload, and typically generates several beams for a given service area bounded by the field of view. The footprints of the beams typically have an elliptic shape and depend on the on-board antenna configuration and the elevation angle. For a transparent payload implementation, a satellite can apply RF filtering and/or frequency conversion and amplification, and refrain from changing the waveform signal. For a regenerative payload implementation, a satellite can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and/or coding/modulation. This approach is effectively equivalent to implementing most of the functions of a base station, e.g., a gNB or an eNB.

[0007] NB-loT and eMTC technologies are expected to be particularly suitable for loT devices operating in remote areas with limited or no terrestrial connectivity. Such loT devices can be used in a variety of industries including for example transportation (maritime, road, rail, air) and logistics; solar, oil, and gas harvesting; utilities; farming; environmental monitoring; and mining. However, to ensure the required loT connectivity, deployment of these technologies requires satellite connectivity to provide coverage beyond terrestrial deployments. Satellite NB-loT or eMTC is defined in a complementary manner to terrestrial deployments.

[0008] After the UE registers with a core network (CN), a CN node manages UE parameters while the UE remains registered with the CN. When the UE is in connection management (CM) idle mode, the CN node pages the UE for a transition to a CM connected mode. During the UE transition to a CM connected mode, the CN node updates the UE parameters during a registration or tracking procedure by including updated parameters in a Non-Access Stratum (NAS) accept message. When the UE is in a connected mode associated with the Radio Resource Control (RRC) sublayer of the radio protocol stack (in which the UE has an active radio connection with a base station), and when the CN determines it should release the NAS signaling connection, the CN notifies the UE accordingly. In response, the UE starts the NAS timer (e.g., T3440 or T3540). Until the timer expires, the UE does not completely release the CM connection. The UE locally releases the established NAS signaling connection upon expiration of the timer.

[0009] In a scenario referred to as a “discontinuous coverage” scenario, a UE is outside of coverage of any terrestrial network and only occasionally or periodically within coverage of an NTN base station. For example, a UE with only satellite access is within coverage of an NTN node for 20 minutes every 10 hours. In these scenarios, managing the NAS signaling connection of the UE presents several challenges for the reasons discussed below.

[0010] When the UE is about to exit NTN coverage, the CN may seek to update UE parameters related to the NTN. Such UE parameters may include power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value for a power saving mode, on duration, off duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of a satellite 304 or 306 associated with the NTN, updated coverage map, etc.), and parameters related to UE mobility in the NTN (e.g., updated tracking area identity (TAI) list, parameters indicating terrestrial or NTN cell changes, etc.). In some implementations, the UE parameters related to the NTN are dynamic, and therefore the CN 110 generates such parameters dynamically rather than statically in advanced. If the UE releases NAS signaling connection after the expiration of the timer, and if the CN node seeks to update the NTN-related UE parameters at that time, the CN node pages the UE and triggers a transition to the CM connected mode. After the CN updates the UE with NTN-related parameters, the CN node releases the NAS signaling connection before the UE moves out of NTN coverage. Thus, this discontinuous coverage scenario requires additional transitions between CM idle and CM connected modes, which consumes radio resources and requires the UE to expend battery power.

[0011] Further, the UE may not have knowledge of NTN coverage or the capability to estimate the time at which the UE will leave NTN coverage. Even when the UE has this capability, the accuracy of such estimations may be poor. In such cases, the UE may attempt to access the CN using initialization NAS procedures for a transition from CM idle mode to CM connected mode before leaving the NTN coverage. If the CN node accepts the initial NAS procedures, the UE may be within coverage for only a short period of time. Thus, the above discontinuous coverage scenario causes an unnecessary transition between CM idle mode and CM connected mode, which similarly results in inefficient use of radio resources and UE’s battery power. Moreover, existing CN timers may be stopped, reset, or otherwise modified by terrestrial network interactions between the CN and the UE, which makes such timers unsuitable for maintaining alignment with NTN coverage.

SUMMARY

[0012] A UE manages network signaling during discontinuous coverage when connected to a CN via an NTN. The UE operating in an idle mode transmits an uplink message to the CN via the NTN. The UE then receives a downlink message including a timer indication from the CN via the NTN. The UE then starts a timer with a duration determined based on the timer indication and uses the timer to control when the UE when the UE attempts to detect a cell associated with the NTN, after an upcoming out- of-NTN-coverage period.

[0013] A CN device communicating with a UE via an NTN receives an uplink message from the UE via the NTN. The CN device then transmits a downlink message including a timer indication, to the UE via the NTN. The CN device may determine the timer indication based on an estimated duration of an upcoming out-of-NTN-coverage period of the UE. The CN device may include NTN communication parameters for the UE in the downlink message.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Fig. 1 is a block diagram of a wireless communication system in which a UE communicates with a CN node via an NTN;

[0015] Fig. 2 is a block diagram illustrating a protocol stack usable by the UE of Fig. 1 to communicates with base stations therein;

[0016] Fig. 3A is a block diagram illustrating an NTN with transparent payload implementation;

[0017] Fig. 3B is a block diagram illustrating an NTN node with transparent payload implementation, in which a base station connects to multiple satellites via the same sat- gateway;

[0018] Fig. 4A illustrates a user plane protocol stack usable with the architecture of Fig. 3A;

[0019] Fig. 4B illustrates a control plane protocol stack usable with the architecture of Fig. 3A;

[0020] Fig. 5A illustrates a scenario in which a UE has satellite coverage during certain time periods separated by intervals of non-coverage; [0021] Fig. 5B illustrates a conventional scenario in which a UE releases a NAS connection after a timer ends;

[0022] Fig. 5C illustrates another conventional scenario in which a UE and a CN enter a CM connected state from a CM idle state for a short period of time before a UE out-of-NTN-coverage period, to update a parameter and then release a NAS connection;

[0023] Fig. 5D illustrates a scenario similar to the scenario in Fig. 5C, but in which the UE and the CN use a timer to indicate when to release the NAS connection, resulting in fewer changes between the CM idle state and the CM connected state;

[0024] Fig. 5E illustrates another scenario similar to the scenario in Fig. 5D, but in which the CN causes the UE to release the NAS connection before the timer expires;

[0025] Fig. 5F illustrates yet another conventional scenario in which the CN rejects a connection request from the UE shortly before a UE out-of-NTN-coverage, and the UE subsequently attempts to resend the request while in an out-of-coverage period for the NTN;

[0026] Fig. 5G illustrates a scenario similar to Fig. 5F, but in which the CN includes a backoff timer indication in the rejection, and the UE refrains from attempting to resend the request until the timer expires;

[0027] Fig. 6A is a messaging diagram of a scenario in which the CN provides timer information to a UE to start a timer, after which the UE will release the connection to the CN, according to an embodiment;

[0028] Fig. 6B is another messaging diagram in which the CN interrupts the timer with a resource release command, according to another embodiment;

[0029] Fig. 7 is yet another messaging diagram in which the CN determines when a UE to leave NTN coverage and a time interval during which the UE is not to attempt to connect with the CN via the NTN, according to an embodiment; [0030] Fig. 8 is a flow diagram of a UE method for determining whether to start a timer as described in Figs. 6A and 6B with a default value or a timer value inferred based on a downlink message, according to an embodiment;

[0031] Fig. 9 is a flow diagram of another UE method for stopping and restarting a timer as described in Figs. 6A and 6B based on whether the UE receives another downlink message while the timer is running, according to an embodiment;

[0032] Fig. 10 is a flow diagram of a CN method for releasing a connection between the UE and the CN when a CN timer expires, according to an embodiment;

[0033] Fig. 11 is a flow diagram of a CN method for pausing a timer when messaging occurs between the UE and the CN via the NTN node, according to an embodiment;

[0034] Fig. 12 is a flow diagram of a UE method for determining when to access an NTN node using a backoff timer as described relative to Fig. 7, according to an embodiment;

[0035] Fig. 13 is a flow diagram of a CN method for transmitting a downlink message including a backoff timer value as described in Fig. 7, according to an embodiment;

[0036] Fig. 14 is a flow diagram of a CN method for determining whether to include NTN parameters in a downlink message with a timer value based on whether a time interval the UE remains in a coverage area for an NTN node is larger than a threshold, according to an embodiment;

[0037] Fig. 15 is a flow diagram of a UE method for managing network signaling during discontinuous coverage, according to an embodiment; and

[0038] Fig. 16 is a flow diagram of a CN method for managing network signaling during discontinuous coverage, according to an embodiment. DETAILED DESCRIPTION

[0039] As discussed in more detail below, a user equipment (UE) and/or a network node of a radio access network (RAN) can use the techniques of this disclosure for managing early data communication and transitioning a UE between states of a protocol for controlling radio resources between the UE and the RAN.

[0040] Referring first to Fig. 1 , a wireless communication system 100 includes a UE 102, a base station 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 can operate in a RAN 105 connected to the core network (CN) 110 and other base station components, such as satellites, as will be described with reference to Figs. 3A and 3B below. The CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160, for example. The CN 110 can also be implemented as a sixth generation (6G) core and future evolutions.

[0041] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 104 is an ng-eNB or eNB, the cell 124 is an evolved universal terrestrial radio access (E- UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 106 is an ng-eNB or eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of terrestrial and nonterrestrial base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the base stations 104 and 106.

Each of the base stations 104, 106 connect to the CN 110 via an interface (e.g., S1 or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0042] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162 and an Access and Mobility Management Function (AMF) 164, and/or Session Management Function (SMF) 166. Generally speaking, the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0043] As illustrated in Fig. 1 , the base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cells 124 and 126 can partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other. To directly exchange messages or information, the base station 104 and base station 106 can support an X2 or Xn interface. In general, the CN 110 can connect to any suitable number of terrestrial and/or non-terrestrial base stations supporting NR cells and/or EUTRA cells.

[0044] As discussed in detail below, the UE 102 and/or the RAN 105 may utilize the techniques of this disclosure when the radio connection between the UE 102 and the RAN 105 is suspended, e.g., when the UE 102 operates in an inactive or idle state of the protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examples below refer to the RRCJNACTIVE or RRCJDLE state of the RRC protocol.

[0045] The base station 104 is equipped with a transceiver and processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non- transitory computer-readable memory storing instructions that the one or more general- purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a processor 132 to process data that the base station 104 will transmit in the downlink direction, or process data received by the base station 104 in the uplink direction. The processing hardware 130 can also include a transmitter 136 configured to transmit data in the downlink direction. The processing hardware further can include a receiver 134 configured to receive data in the uplink direction. The processing hardware further can include an RRC controller 138 to implement procedures and messaging at the RRC sublayer of the protocol communication stack. The base station 106 can include generally similar components. A CN node 110 hosting and performing one or more of the above-described modules and functions includes components 140, 142, 144,146, and 148 that are similar to the components 130, 132, 134, 136, and 138 respectively.

[0046] The UE 102 is equipped with a transceiver and processing hardware 150 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. The processing hardware 150 in an example implementation includes a processor 152 to process data that the UE 102 will transmit in the uplink direction, or process data received by UE 102 in the downlink direction. The processing hardware 150 can also include a transmitter 156 configured to transmit data in the downlink direction. The processing hardware further can include a receiver 154 configured to receive data in the uplink direction. The processing hardware further can include an RRC controller 158 to implement procedures and messaging at the RRC sublayer of the protocol communication stack.

[0047] Fig. 2 illustrates, in a simplified manner, a protocol stack 200 according to which the UE 102 can communicate with an eNB/ng-eNB or a gNB (e g., one or more of the base stations 104, 106) labeled 201 and 203 in this figure.

[0048] In the protocol stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2). The UE 102, in some implementations, supports both the ELITRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0049] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0050] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide Data Radio Bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0051] Fig. 3A illustrates a certain type of NTN deployment referred to as transparent payload architecture, which involves a satellite gateway 302 and a “transparent” satellite 304 for extending the range of the Uu interface. The satellite 304 implements a frequency conversion and a Radio Frequency (RF) amplifier in both the uplink and downlink directions. The satellite function is similar to that of an analogue RF repeater. As a result, the satellite 304 repeats the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the service link (between the satellite and the UE) in the downlink direction and vice versa in the uplink direction. The Satellite Radio Interface (SRI) on the feeder link is the Uu, and the NTN gateway 302 supports all necessary functions to forward the signal of the Uu interface. The NTN gateway 302 can be placed at the same location as the base station (e.g., eNB, gNB) 104, or be connected to the base station 104 at a distance via a wired link. It is also possible to connect more than one NTN gateway to a base station. Different transparent satellites may be connected to the same base station on the ground, via the same NTN gateway, or via different NTN gateways.

[0052] Fig. 3B illustrates the implementation in which two different satellites (304 and 306) connect to the same base station 104 via the same NTN gateway 302, and these two satellites (304 and 306) are covering the Earth surface using two different Physical Cell IDs (PCIs).

[0053] Next, Fig. 4A illustrates an NTN user-plane protocol stack 400A involving the UE 102, the satellite 304, the NTN gateway 302, the base station 104, and the EPC S- GW 112 (or 5GC SMF 166). The NTN user-plane protocol stack is similar to that of the terrestrial network (TN), except that the configuration of Fig. 4A illustrates two additional nodes, the satellite 304 and the NTN gateway 302, operating in the middle of the Uu interface. Fig. 4A illustrates an NTN user-plane protocol stack 400B involving the UE 102, the satellite 304, the NTN gateway 302, the base station 104, and the EPC MME 114 (or 5GC AMF 164). Similar to the NTN user-plane protocol stack 400A, the NTN control plane protocol stack 400B illustrated in Fig. 4B is also generally analogous to that of the TN counterpart shown in Fig. 2.

[0054] Referring generally to Figs. 1-4B, NTN supports at least three types of service links NTN, described in terms of satellite movement patterns: (i) Earth-fixed: provisioned by beam(s) continuously covering the same geographical areas all the time (e.g., the case of GEO/GSO satellites); (ii) Quasi-Earth-fixed: provisioned by beam(s) covering one geographic area for a limited period and a different geographic area during another period (e.g., the case of LEO/MEO satellites capable of using steerable beams); and (iii) Earth-moving: provisioned by beam(s) whose coverage area slides over the Earth surface (e.g., the case of LEO/MEO satellites using fixed or non-steerable beams). [0055] With LEO/MEO satellites, a base station can provide either quasi-Earth-fixed cell coverage or Earth-moving cell coverage. With GEO satellites, the base station can provide Earth fixed cell coverage.

[0056] Although the transparent payload architecture illustrated in Figs. 3A and 3B is the current focus of the 3GPP development, the regenerative payload architecture that places some of the base station functions on the satellite is also a possible NTN deployment in the future. In such an architecture, the Uu only exists between the satellite and the UE. In general, the techniques of this disclosure can apply to the transparent payload architecture as well as the regenerative payload architecture.

[0057] Again referring generally to Figs. 1-4A, the UE 102 operating in a certain cell must be able to detect reference signals from the neighboring cells and measure the strength of the reference signals to be able to switch to a qualified neighboring cell when needed (i.e. , when the serving cell is no longer able to serve the UE due to poor signal reachability), or in order to add a new Carrier Component (CC). The reference signal a base station can use for this purpose with the NR radio interface is the synchronization signal (SS) and physical broadcast channel (PBCH) block, abbreviated as SSB. Unlike the LTE radio interface in which a base station transmits SS every 5 ms, 5G NR allows each base station to transmit the SSB burst with different time patterns, with the longest periodicity of up to 160 ms. This allows the network to configure the SSB transmission in a more dynamic manner dependent on the actual usage and channel condition.

[0058] This approach helps to avoid unnecessary measurements and reduce the power consumption of a UE. However, this flexibility comes at the cost of the additional signaling required to inform the UE when to perform measurement on a measurement target. Without the additional signaling, the UE would need to assume the worst-case scenario (in the implementation above, the 5 ms periodicity) to determine when to measure the target. As a result, the UE achieves no power saving gain. This additional signaling in 5G NR is known as “SSB based measurement timing configuration (SMTC),” which contains a periodicity setting ranging from 5 ms to 160 ms and a duration setting ranging from 1 ms to 5 ms. [0059] The network does not need to align the SMTC periodicity setting with the actual SSB burst periodicity. For instance, the SMTC periodicity can be set to a value larger than the SSB burst periodicity to further reduce the power consumption of the UE. In addition to the periodicity and duration settings, the SMTC also indicates a timing offset to inform the UE of the exact subframe where the UE should start monitoring the SSB burst, which occurs repeatedly according to the periodicity setting. A base station can signal the periodicity and the timing offset settings together, in one measurement object, as a single parameter pe odicityAndOffset.

[0060] There can be a relatively small timing difference between the timing of the Primary Cell (PCell) and the timing of the measurement target, in part due to the propagation delay difference. A terrestrial network can ignore this small timing difference, as the propagation delay difference is small and hence requires no adjustment in the timing offset setting. Accordingly, 3GPP TS 38.331 (v16.6.0) currently specifies only one timing offset for the measurement object configuration. For a nonterrestrial network, however, the propagation delay between a satellite and a UE could be longer (e.g., up to 25.77 ms), and the variance for different satellites can be significant (e.g., between 8 ms and 25.77 ms).

[0061] A UE and/or a base station can use an individual timing offset setting associated with each respective measurement target (i.e. , a satellite) configured in a measurement object. This approach can result in multiple timing offsets settings or even multiple SMTCs configured in one measurement object. Although a measurement object can support two SMTCs, these SMTCs currently must share the same timing offset setting and hence cannot address the propagation delay issue in an NTN discussed above.

[0062] Fig. 5A illustrates a scenario 500A in which the UE 102 may experience discontinuous coverage from an NTN due, for example, to a sparse satellite constellation deployment. In the scenario 500A, the UE 102 is within a first coverage zone 314 served by the LEO satellite 304 from t1 to t2, and within a second coverage zone 316 served by another LEO satellite 306 from t3 to t4. In the period between t2 to t3, however, the UE 102 is not served by any satellite or any terrestrial base station, and therefore is out of a coverage zone for the NTN nodes. Typically, when a UE 102 loses coverage by a serving cell, the UE 102 starts searching for other cells and then camps on a suitable cell. However, in the example illustrated in Fig. 5A, even if the UE 102 starts searching for other cells immediately after t2, the UE 102 does not find a cell. Moreover, depending on the implementation, the cell search lasts for a long time, as the time period between t2 to t3 can vary from tens of minutes to hours. Therefore, the cell search causes extra, unnecessary power consumption in the UE 102.

[0063] To reduce power consumption at the UE in such scenarios as the one depicted in Fig. 5A, the UE 102 may not be required to perform the cell search and can deactivate the Access Stratum (AS) functions during the period when the UE is not within the area of coverage of a satellite. In some implementations, the UE 102 has knowledge of when the UE 102 will be outside the area of coverage, and when the UE 102 will be within an area of coverage again, in order to reactivate the cell search or AS functions before the UE 102 falls into the coverage of another NTN cell. For example, the ephemeris information broadcast in the system information provides the constellation and trajectory or movement information of nearby satellites (e.g., the serving and the neighboring satellites), which helps the UE 102 to estimate when the UE 102 will be within or outside the NTN coverage. In addition to the ephemeris information, the UE 102 may use other information to estimate coverage of a NTN cell more precisely.

[0064] In some scenarios, the UE 102 in a connected state (e.g., RRC_CONNECTED state) communicates with a RAN (e.g., RAN 105) via the satellite 304 and detects radio link failure on the service link with the satellite 304 because the UE 102 is out of coverage of the satellite 304 (e.g., in the period between t2 to t3). In response to the radio link failure, the UE 102 initiates an RRC connection reestablishment procedure (e.g., in accordance with 3GPP specification 38.331 ).

[0065] Fig. 5B illustrates operations for releasing a NAS signaling connection for a UE 102 in a connected mode in preparation for the UE 102 to exit the coverage zone associated with a node of the NTN (e.g., satellite 304). The UE 102 receives an indication 510B from the CN (e.g., CN 110) via the NTN notifying the UE 102 of the impending signaling connection release. The UE 102 begins a NAS timer 590B (e.g., timer T3440 for Evolved Packet Systems (EPS) operations or T3540 for 5G System (5GS) operations). The timer 590B (e.g., T3440/T3540) has a default duration (e.g., 10 seconds) consistent for the timer 590B. Until the timer 590B expires, the UE 102 will not completely release the connection. For example, the UE 102 stops the timer 590B if the UE 102 is to perform operations 560B, such as receiving information or transmitting information to the CN 110 (e.g., Mobile Originated (MO) data, Mobile Terminated (MT) signaling, etc.). After performing operations 560B, the UE 102 may restart the timer value and again count down before releasing 550B the connection and entering idle mode.

[0066] Fig. 5C illustrates a conventional operation resulting in an undesirable large power consumption. In particular, the CN 110 enters 505C an idle mode and notifies 510C the UE 102 of the NAS signaling connection release (e.g., to cause the UE 102 to enter a CM idle mode). The UE 102 activates a timer 590C (e.g., a T3440/T3450 timer as described above) and, after the timer 590C expires, the UE 102 releases 550C the NAS signaling connection and enters a CM idle mode 527C (the CN simultaneously assuming 526C the UE is in idle mode).

[0067] In some implementations, when the UE 102 is to move out of NTN coverage, such as in the discontinuous coverage scenarios discussed herein, the CN 110 may need to update parameters regarding the NTN. In various implementations, the NTN parameters include any or all of power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value for a power saving mode, on duration, off duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of a satellite 304 or 306 associated with the NTN, updated coverage map, etc.), and parameters related to UE mobility in the NTN (e.g., updated tracking area identity (TAI) list, parameters indicating terrestrial or NTN cell changes, etc.). However, the CN 110 may try to update the NTN related parameters for the UE 102 after the UE 102 has released 550C the NAS signaling connection (e.g., after the expiration of the timer described above with regard to Fig. 5B). As such, when the CN 110 detects 525C that the UE 102 will leave the NTN coverage zone (e.g., coverage zone 314 in Fig. 5A), the CN pages (i.e. , sends a paging message to) the UE to transition to connected mode. Thus, the UE 102 receives 520C the paging message and transitions to a connected CM mode 527C. The CN 110 updates 535C the parameters (e.g., using TAU for EPS and registration or RNAU procedures for 5GS) and releases the connection, returning to a CM idle mode. Similarly, the UE 102 releases 530C the connection and returns to a CM idle mode.

[0068] The scenario 500C for a UE 102 connecting with a CN 110 via an NTN with discontinuous coverage requires additional transitions between idle mode and connected mode, which wastes radio resources and battery power of the UE. By introducing a new timer when the CN 110 is releasing the connection with the UE 102, the UE 102 avoids such waste while minimally extending the time spent active in a discontinuous coverage period, thereby improving the power, resource use, and overall operation of the UE 102.

[0069] Fig. 5D illustrates a scenario 500D similar to scenario 500C, but in which the UE 102 and the CN 110 use timers to indicate when to release the NAS connection, resulting in fewer changes between the CM idle state and the CM connected state. In particular, when the CN 110 determines 505D to enter an idle mode and notifies 510D the UE 102 of the NAS signaling connection release, the CN 110 includes a timer value and/or indication, as described in more detail below with regard to Figs. 6A and 6B. The UE 102 starts a NAS release timer 595D and the CN 110 starts a NAS release timer 596D with a similar or same value. Then, when the network detects that the UE 102 will leave the NTN coverage, the CN 110 updates parameters for the UE 102, which the UE 102 receives 520D while remaining in the connected mode, eliminating the additional transitions to and from the connected mode in scenario 500C. In some implementations, the UE 102 and the CN 110 restart the timers 528D and 529D according to a value included in the parameter message received 520D by the UE 102, the initial value received 510D by the UE 102 in the initial message, a default value, or some other value as described in more detail with regard to Fig. 6A below. The timers then expire at 530D and 535D respectively, causing the UE 102 and the CN 110 to naturally release the CM connection, as described in more detail below with regard to Fig. 6A.

[0070] Fig. 5E illustrates another scenario 500E similar to scenario 500D, but in which the CN 110 causes the UE 102 to release the NAS connection before the timer expires. In particular, after restarting the timers 528E and 529E, the CN 110 determines 535E to release the NAS connection and transmits an indication to the UE 102 to release 530E the connection, as described in more detail below with regard to Fig. 6B.

[0071] Fig. 5F illustrates yet another scenario 500F in which the CN 110 rejects an attempt by the UE 102 to connect to the CN 110, after which the UE 102 continues to attempt to connect. In particular, the UE 102 attempts 540F to connect to the CN 110 (e.g., using a TAU message, a registration message, etc.). The CN 110 determines that the UE 102 will exit NTN coverage soon, as described below in greater detail with regard to Fig. 7 and rejects 575F the attempt. The UE 102 receives 570F the rejection and remains in the idle mode. At a later time, the UE 102 attempts 598F to connect with the CN 110 via the NTN, but is unable to connect, as the UE 102 is out of the NTN coverage. As such, the UE 102 continues to attempt to connect to the CN 110 until reentering the NTN coverage zone (e.g., at coverage zone 306 described above with regard to Fig. 5A), where the UE 102 successfully connects 580F and 585F with the CN 110.

[0072] Fig. 5G illustrates a scenario 500G similar to scenario 500F, but in which the CN 110 includes a backoff timer indication in the rejection, and the UE 102 refrains from resending the request until the backoff timer expires. In particular, when the CN 110 rejects the attempt to connect, the CN 110 includes a backoff timer value that the UE 102 receives 570G and uses to generate a backoff timer 597G (e.g., as described in greater detail below with regard to Fig. 7). The UE 102 uses the backoff timer 597G and stays in the idle state until after the timer 597G expires 580G. The UE 102 then is back in coverage and connects 585G with the CN 110.

[0073] Next, several example scenarios that involve several components of Fig. 1 and relate to detecting out of coverage in an inactive or connected state are discussed next with reference to Figs. 6A-7. Generally speaking, similar events in Figs. 6A-7 are labeled with the same or similar reference numbers, with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures and also to both integrated and distributed base stations.

[0074] Fig. 6A illustrates a messaging diagram 600A of a UE 102 communicating with a CN 110 via a base station 104 including the satellite 304. The messaging diagram 600A corresponds to the scenario 500D in Fig. 5D described above. The UE 102, which initially operates 602 in a connected state in coverage of the satellite 304, establishes 604 a NAS signaling connection with the CN 110 (e.g., the MME 114 for EPS or AMF 164 for 5GS). For example, in some implementations, the connected state is an ECM-CONNECTED state or EMM-CONNECTED state for an MME 114. In further implementations, the connected state is a 5GCM-CONNECTED state or 5GMM- CONNECTED state in the case of the AMF 164. In still further implementations, the connected state is an RRC_CONNECTED state.

[0075] The UE 102 communicates 606 data and/or signaling with the CN 110 via the base station 104 (e.g., an NTN node such as satellite 304) while operating in a connected state. In the following description, any description of messages, data and/or signaling between the UE 102 and CN 110 are to be construed as communicated via the base station 104 unless noted otherwise. After receiving 606 the data and/or signaling, the CN 110 transmits 608 a NAS signaling connection release message to the UE 102 in order to cause the UE 102 to transition to an idle state. In some implementations, the NAS signaling connection release message 608 includes NAS signaling connection management information for the UE 102. The NAS signaling connection management information is used to inform the UE 102 when to release the NAS signaling connection.

[0076] In some implementations, the NAS signaling connection release message 608 is a NAS message (e.g., as specified in the clause 5.3.1 .2.1 of 3GPP TS 24.301 ). In further implementations, the NAS signaling connection release message 608 is or includes a tracking area message (e.g., a TRACKING AREA UPDATE ACCEPT message or a TRACKING AREA UPDATE REJECT message), a UE operation message (e g., a DETACH ACCEPT message or an ATTACH ACCEPT message), or a service message (e.g., a SERVICE ACCEPT message or a SERVICE REJECT message) as specified in 3GPP TS 24.301 . In other implementations, the NAS signaling connection release message 608 is or includes a registration message (e.g., a REGISTRATION ACCEPT message, a REGISTRATION REJECT message, or a DEREGISTRATION ACCEPT message), a service message (e.g., a SERVICE ACCEPT message or a SERVICE REJECT message), or a configuration message (e.g., a CONFIGURATION UPDATE COMMAND message) as specified in 3GPP TS 24.501 . Depending on the implementation, the CN 110 includes a timer value in the NAS signaling connection release message 608. In some implementations, the time value is a value according to the type of NAS signaling connection release message 608. For example, the CN 110 may include a TAU timer value when the NAS signaling connection release message 608 is a tracking area update message. In further such implementations, the CN 110 modifies the value to be longer or shorter depending on a remaining NTN coverage time for the UE 102. In further such implementations, the CN 110 includes a timer value such as a TAU timer as well as a quantity by which to modify the timer in question.

[0077] After the UE 102 receives 608 the NAS signaling connection release message, the UE 102 determines 610 a first timer value based on the NAS signaling connection management information and starts 612 a UE timer (i.e. , UE NAS signaling connection release timer) based on the first timer value. Similarly, after the CN 110 transmits 608 the NAS signaling connection release message, the CN 110 starts 613 a corresponding network timer for releasing the NAS signaling connection with the first timer value or a timer value close to the first timer value, based on the NAS signaling connection management information. The network timer can be a broad NAS timer or can be an implementation-specific timer. [0078] In some implementations, the UE timer (e.g., NAS release timer 596D or 596E) is a timer for EPS and has a default duration equivalent to other EPS timers (e.g., timer T3440 as specified in 3GPP TS 24.301 ). In further implementations, the UE timer (e.g., NAS release timer 596D or 596E) is a timer for 5GS and has a default duration equivalent to other 5GS timers (e.g., timer T3540 as specified in 3GPP TS 24.501 ). In yet further implementations, the UE timer is a timer for 6G and has a default duration equivalent to other such timers. In some implementations, such as in cases where the CN 110 does not include the NAS signaling connection management information in the message 608, the first timer value is a first default timer value (e.g., default NAS signaling connection release timer value). Depending on the implementation, the UE 102 is preconfigured to store the default timer value and the NAS signaling connection management information indicates to the UE 102 to use the default timer value.

[0079] In some implementations, the NAS signaling connection management information includes the timer value. In further implementations, when the CN 110 determines to transmit the message 608, the CN 110 estimates when the UE 102 will leave the coverage zone of the satellite 304. In such implementations, the CN 110 then determines the timer value based on the estimation. For example, the CN 110 estimates that the UE 102 will leave the coverage after a particular time period (e.g., 18 seconds), and the CN 110 sets the timer value greater than or equal to the time period. The UE 102 determines the timer value as received in the NAS signaling connection management information.

[0080] In further implementations, the NAS signaling connection management information includes an offset value for a default timer value (e.g., 10 seconds, 20 seconds, 30 seconds, etc.). The UE 102 derives the timer value as the offset value plus the default timer value. For example, the default timer value is 10 seconds and the CN 110 estimates that the UE 102 leaves the coverage after a particular time period (e.g., 18 seconds). In this example, the CN 110 sets the offset value to +8 seconds. In another example, the default timer value is 10 seconds and the CN 110 estimates that the UE 102 leaves the coverage after a particular time period (e.g., 8 seconds). In this example, the CN 110 sets the offset value to -2 seconds. [0081] In further implementations, the NAS signaling connection management information includes a multiplier applied to the default timer value. For example, the CN 110 estimates that the UE 102 leaves the coverage after a particular time period and sets the multiplier to a celling value of (the time period)/(the default NAS signaling connection release timer value). When the UE 102 receives the multiplier in the NAS signaling connection management information, the UE 102 derives the timer value as the default timer value multiplied by the multiplier. For example, the timer period is 18 seconds, and the first default timer value is 10 seconds. In this example, the CN 110 sets the multiplier to 2. Thus, the UE 102 derives the NAS signaling connection release timer value as 20 seconds which is 10 seconds multiplied by 2.

[0082] In some implementations, the UE 102 is preconfigured with the timer value, and the NAS signaling connection management information includes an indication for the UE 102 to apply the timer value. In some such implementations, the UE 102 is preconfigured with multiple timer values, and the NAS signaling connection management information includes an indication for which timer value the UE 102 should apply. For example, a UE 102 is preconfigured with timer values for 10, 15, 20, and 30 seconds. The NAS signaling connection management information includes a binary flag that differentiates which timer value the UE 102 should select (e.g., 00 indicating a timer value of 10 seconds, 01 indicating 15 seconds, 10 indicating 20 seconds, and 11 indicating 30 seconds. In some implementations, the preconfigured timer value(s) includes a timer value for another timer (e.g., timer T3440/T3540) and one of the potential indicators is to use such a timer in determining the value.

[0083] In some implementations, the CN 110 can communicate 614 with the UE 102 (e.g., transmit downlink data or signaling and/or receive uplink data or signaling) while the network timer is running. Depending on the implementation, the communications between the CN 110 and the UE 102 may be mobile terminating (MT) or mobile originating (MO). The UE 102 can stop 616 the UE timer in response to the communicating 614 and/or the CN 110 can stop 617 the network timer when determining to communicate. Depending on the implementation, the CN 110 stops the timer by temporarily pausing the timer, restarting the timer (e.g., in conjunction with starting 621 the timer as described below), and/or releasing the timer (e.g., in releasing the connection with the UE 102 as described in Fig. 6B below with regard to event 631 ). In some implementations, the communicating 614 includes one or more downlink (DL) NAS messages (e g., a GlITI REALLOCATION COMMAND message, a CONFIGURATION UPDATE COMMAND message, and/or a DL NAS Transport message). In further implementations, the downlink data includes user data (e.g., one or more Internet Protocol packets). In further implementations, the communicating 614 includes one or more uplink (UL) NAS messages from the UE 102 that cause the CN 110 to transmit a response and/or another downlink message. Depending on the implementation, the UL NAS messages may be or include an attach request message, a TAU request message, a service request message, a registration request message, a detach request message, a deregistration request message, and/or an UL NAS transport message.

[0084] In some implementations, the CN 110 transmits 618 a DL NAS message including NTN related UE parameters to the UE 102 while the network timer is running. Examples of the NTN related UE parameters include power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value for a power saving mode, on duration, off duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of a satellite 304 or 306 associated with the NTN, updated coverage map, etc.), and parameters related to UE mobility in the NTN (e.g., updated tracking area identity (TAI) list, parameters indicating terrestrial or NTN cell changes, etc.). In some implementations, the UE parameters related to the NTN are dynamic, and therefore the CN 110 generates such parameters dynamically rather than statically in advanced. Examples of the DL NAS message include a TRACKING AREA UPDATE ACCEPT message, a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message.

[0085] In some implementations, the DL NAS message 618 includes another set of NAS signaling connection management information for the UE 102 to determine a second timer value for the first timer, similar to the event 608. After or in response to receiving the NAS signaling connection management information 618, the UE 102 determines a second timer value based on the NAS signaling connection management information 618 and starts or restarts 620 the UE timer with the second timer value. In implementations where the DL NAS message 618 does not include another set of NAS signaling connection management information, the UE 102 can start or restart the UE timer with the first timer value or a default timer value. In some implementations, after the CN 110 transmits the DL NAS message 618, the CN 110 starts or restarts 621 the network timer with the second value or a value similar to the second value. In implementations where the DL NAS message 618 does not include another set of NAS signaling connection management information, the CN 110 starts the network timer with the value that the CN 110 used or determined in the event 613.

[0086] The events 614, 616, 617, 618, 620, and 622 are collectively referred to in Fig. 6A as a Data/Signaling Communication procedure 680, which can be optional.

[0087] Later in time, the UE 102 detects 622 that the UE timer expires. Upon expiry of the UE timer, the UE 102 releases 624 the NAS signaling connection and transitions 626 to an idle state from the connected state. In some implementations, the idle state is an ECM-IDLE state or EMM-IDLE state for an MME 114. In further implementations, the ide state is a 5GCM-IDLE state or 5GMM-IDLE state for an AMF 164. Similarly, later in time, the CN 110 detects 623 that the network timer expires. Upon expiry of the network timer, the CN 110 releases 625 the NAS signaling connection and determines that the UE operates in the idle state. In some implementations, the CN 110 can transmit 628 a release command (e.g., a UE Context Release Command message) to the base station 104 to cause the base station 104 to remove a UE context. In response, the base station 104 releases the UE context and transmits a completion message (e.g., a UE Context Release Complete message) to the CN 110.

[0088] In some implementations, the UE 102 applies the latest received NAS signaling connection management information or the latest timer value determined based on the latest received NAS signaling connection management information until the next tracking area update procedure or the next registration procedure. If the UE 102 receives no NAS signaling connection management information in a tracking area accept message or registration accept message in the next tracking area update procedure or the next registration procedure, the UE applies the first default timer value for the UE timer. In such cases, the CN 110 also uses the first default timer value for the network timer or determines a value close to the first default timer value for the network timer.

[0089] Fig. 6B illustrates a messaging diagram 600B in which the UE 102 communicates with the base station 104 of the RAN 105 that includes a satellite 304. The messaging diagram 600B is similar to the messaging diagram 600A, except for the message exchanges and actions occurring after the UE 102 and the CN 110 start the timer for NAS signaling connection release with the first value or the second value (e.g., events 612/613 and/or 620/621/680). The messaging diagram 600B corresponds to the scenario 500E of Fig. 5E described above. While the UE timer and the network timer are running, the CN 110 transmits a UE Context Release message 628 to the base station 104 to initiate the signaling connection release procedure, and the base station 104, in response, transmits an RRC release message 629 to the UE 102. Depending on the implementation, the CN 110 may determine to release the UE 102 due to an indication from the UE 102 or the base station 104 (e.g., that the UE needs to immediately end the connection or reallocate radio resources), due to a determination by the CN 110 (e.g., that the UE 102 will soon leave coverage of the satellite 304), due to an indication from another base station (e.g., a handover to base station 106), etc. In further implementations, the base station 104 determines that an RRC or AS connection should be released as a base station-specific inactivity timer expires. In such implementations, the base station 104 causes the UE 102 to end the connection without prompting from the CN 110.

[0090] An AS layer or an RRC layer of the UE 102 indicates to a NAS layer that the RRC connection is released after the UE 102 receives RRC release message 629. The NAS layer of the UE 102 stops the UE timer 630 and considers the NAS signaling connection released 624, which causes the UE 102 to transition to an idle state 626. After the CN 110 transmits a UE Context Release message 628 to the base station 104, the CN 110 stops the network timer 631 and releases the NAS signaling connection 625, which transitions the UE state to an idle state.

[0091] Fig. 7 is yet another messaging diagram 700 exchanged between a UE 102 and a CN node 110 via the base station 104 of the RAN 105 that includes a satellite 304 and a satellite 306. The CN 110 corresponds to an MME 114 for EPS and/or an AMF 164 for 5GS. The messaging diagram 700 corresponds to the scenario 500G in Fig. 5G described above. The UE 102 initially operates 702 in a coverage zone of the satellite 304. For example, the UE 102 operating in an idle state 704 (e.g., ECM-IDLE state or EMM-IDLE state for EPS and 5GCM-IDLE state or 5GMM-IDLE state for 5GS) is in a coverage zone for the satellite 304. The UE 102 attempts to access the CN for a transition to a connected state by transmitting an uplink (UL) NAS message 706 to the CN 110. In various implementations, the UL NAS message 706 is or includes a service message (e g., a SERVICE REQUEST message or a CONTROL PLANE SERVICE REQUEST message) or a tracking message (e.g., a TRACKING AREA UPDATE REQUEST message) for EPS, and a service message (e.g., a SERVICE REQUEST message or a CONTROL PLANE SERVICE REQUEST message) or a registration message (e.g., a REGISTRATION REQUEST message) for 5GS.

[0092] After receiving the UL NAS request message 706, the CN 110 checks an estimated time until the UE leaves NTN coverage 708. The estimation is done by the CN 110 or other entities (e.g., a 3^rd party server or application server). If the estimation is under a predefined threshold, which means that the UE is leaving NTN coverage within a short period of time, the CN 110 decides to reject the initial NAS request. In some implementations, the CN 110 determines 710 the backoff timer value based on the estimation 708. For example, if the estimation 708 is that the UE 102 will leave the coverage in about 5 minutes, the CN 110 determines to have the UE 102 refrain from attempting access the network by setting up a backoff timer greater than 5 minutes. In some implementations, the estimation includes both the time until the UE 102 leaves NTN coverage and the time for which the UE 102 stays out of NTN coverage (e.g., the estimated remaining time until the UE comes back to the next NTN node coverage zone). In some such implementations, the backoff timer causes the UE 102 to refrain from attempting access before the UE 102 leaves the coverage zone and after the UE 102 moves out of coverage, which will reduce unnecessary signaling and power consumption. In some implementations, the CN 110 determines the NTN related UE parameters and provides them to the UE 102. In various implementations, the NTN related UE parameters includes, but is not limited to, power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value for a power saving mode, on duration, off duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of a satellite 304 or 306 associated with the NTN, updated coverage map, etc.), and parameters related to UE mobility in the NTN (e.g., updated tracking area identity (TAI) list, parameters indicating terrestrial or NTN cell changes, etc.).

[0093] After the CN 110 decides 708 to reject the UL NAS message 706 and determines 710 the backoff timer value, and the NTN related UE parameters, the CN 110 transmits a DL NAS message 712 to the UE 102. Depending on the implementation, the DL NAS message 712 is an action rejection responding to the request made by the UE 102 in the UL NAS message 706. As such, in various implementations, the DL NAS message 712 includes a service or tracking message (e.g., a SERVICE REJECT message or a TRACKING AREA UPDATE REJECT message) for EPS and a service or registration message (e.g., a SERVICE REJECT message or a REGISTRATION REJECT message) for 5GS. The DL NAS message 712 includes an EMM cause or 5GMM cause value and backoff timer value determined in the event 710. In some implementations, the DL NAS message 712 also includes the NTN related UE parameters.

[0094] In some implementations, the cause value included in the NAS reject message 712 is a new cause value indicating that the UE is going to leave the coverage zone soon. In some implementations, the new cause code is #XX (leaving NTN coverage). In other implementations, the cause value is an existing cause value, such as #15 (i.e. , no suitable cells in tracking area) or #22 (i.e., congestion). In some implementations, the backoff timer value included in the NAS reject message 712 is a GPRS timer value (e.g., as defined in 3GPP TS 24.008).

[0095] After receiving the DL NAS message 712, the UE 102 starts a backoff timer 714. In some implementations, the backoff timer is a new timer (e.g., a NAS timer T34XX or T35XX), which prohibits the UE 102 from attempting an access operation for the core network before an expiry of the timer. The new timer stops when the CN 110 sends paging for any downlink signaling and/or data, or the CN 110 sends downlink signaling. The new timer also stops when the UE 102 selects a cell which is not an NTN cell or selects a TN (terrestrial network) cell. In some implementations, the new timer does not stop when the core network changes (e.g., the timer keeps running if the UE 102 moves from the EPS to the 5GS or vice versa) and continues to restrict the UE 102 from accessing the core network. In other implementations, the backoff timer is an existing NAS timer (e.g., timer T3346).

[0096] In some implementations, if the backoff timer value is not included in the DL NAS message 712, the UE 102 starts the backoff timer with a random value within a predefined range, or with a predefined default value.

[0097] After receiving the DL NAS message 712, the UE 102 releases the NAS signaling connection 724, or starts NAS timer T3440 (e.g., for EPS) or T3540 (e.g., for) 5GS and releases the connection on the expiry of the timer, which causes the UE 102 to transition to an idle state 726. In some implementations, the CN 110 can transmit a UE Context Release message 728 to the base station 104 to initiate the signaling connection release procedure, and the base station 104, in response, transmits an RRC release message 729 to the UE 102. An AS layer or RRC layer of the UE 102 indicates to the NAS layer that the RRC connection is released after the UE 102 receives RRC release message 729. The NAS layer of the UE 102 considers the NAS signaling connection released 724, which causes the UE 102 to transition to an idle state 726. The CN 110 considers the UE 102 to have entered an idle state 725 after transmitting the DL NAS message 712 or after transmitting a UE Context Release Command message 728. After the UE 102 detects it is out of NTN coverage 732, the UE 102 continues to run the backoff timer. In some implementations, the UE 102 turns off the radio or stops searching for another NTN cell in order to reduce power consumption.

[0098] When the backoff timer expires in the UE 102 and the UE 102 detects that it is in the NTN coverage zone of a satellite 306, the UE 102 transmits the UL NAS message 736 if the message is still required. If the UE 102 detects that it is in the coverage of a non-NTN cell or a TN (terrestrial network) cell and successfully camps on the cell, the UE 102 stops the backoff timer and transmits the UL NAS message 736 if the message is still required.

[0099] In some implementations, the UE 102 considers the DL NAS message 712 valid only when the message is integrity protected. For example, if the message is not integrity protected nor successfully checked as integrity protected, the UE 102 discards the DL NAS message 712.

[0100] Next, several methods that can be implemented in a UE (e.g., the UE 102) or a CN node operating as an MME or performing an AMF are discussed with reference to Figs. 8-14. Each of these methods can be implemented using processing hardware such as one or more processors to execute instructions stored on a non-transitory computer-readable medium such as a computer memory.

[0101] Referring first to Fig. 8, a UE method 800 can be implemented in a suitable UE (e.g., 102) and includes determining a value to use for starting a timer according to the contents of signaling management information and determining how to release a signaling connection based on whether the UE receives a release message. For clarity, the method 800 is discussed with reference to the RAN 105, base station 104, the CN 110, the UE 102, and the satellite 304.

[0102] At block 802, the UE 102 establishes a signaling connection with a CN 110 via a RAN 105 (e.g., event 604 of Figs. 6A and 6B). In some implementations, the signaling connection is a NAS signaling connection with the CN 110 via an NTN node, such as satellite 304 of a discontinuous NTN. At block 804, the UE 102 communicates one or more messages with the CN 110 via the RAN 105 (e.g., event 606 of Figs. 6A and 6B). In implementations in which the signaling connection is a NAS signaling connection via the NTN node, the messages are NAS messages between the UE 102 and the CN 110, transmitted while the UE 102 is within a coverage area associated with the NTN node.

[0103] At block 806, the UE 102 receives a downlink message (i.e. , a DL NAS message) from the CN 110 via the RAN 105 (e.g. , event 608 of Figs. 6A and 6B). At block 808, the UE 102 determines whether the downlink message includes signaling connection management information (i.e., NAS signaling connection management information) (e.g., event 610 of Figs. 6A and 6B). If the downlink message does include the signaling connection management information, then flow proceeds to block 810. If not, then flow instead proceeds to block 814.

[0104] At block 810, the UE 102 determines a timer value based on the signaling connection management information (e.g., event 610 of Figs. 6A and 6B). The signaling connection management information may be or include the signaling connection management information as described above with regard to Figs. 6A and 6B. As such, the signaling connection management information may include information such as a timer value, an amount by which to modify a default timer, an indication to use a default timer, a binary flag indicating whether to use one of two timers, etc. The UE 102 may therefore determine the timer value by using the timer value provided, by modifying a default timer value, by selecting a timer value based on a flag, etc. At block 812, the UE 102 starts a timer according to the determined timer value (e.g., event 612 of Figs. 6A and 6B).

[0105] At block 814, the UE 102 starts the timer according to a default timer value (e.g., event 610/612 of Figs. 6A and 6B). It will be understood that, although block 814 specifically notes the default timer value, that the UE 102 may use a default timer value at block 812 based on the contents of the downlink message as described with regard to block 810. Similarly, the default timer value at block 814 may be UE-specific, may be a broader timer applicable to a general RAN or CN, may be indicated by the CN 110 at an earlier time (e.g., when initially connecting via the RAN 105), etc. [0106] After setting the timer, the UE 102 and the CN 110 eventually will plan to release the connection for the UE 102 responsive to the timer stopping. Depending on the implementation, the CN 110 may force the connection to release (e.g., as depicted in Fig. 6B above) or may allow the connection to release naturally (e.g., as depicted in Fig. 6A above). As such, at block 816, the UE 102 determines whether the UE receives an RRC release message and determines whether to force the connection to release. In some such implementations, then, at block 818, the UE 102 stops the timer in response to receiving the RRC release message (e.g., event 629/630 of Fig. 6B). In other implementations, at block 820, the UE 102 detects that the timer expires (e.g., event 622 of Fig. 6A). Then, at block 822, the UE 102 releases the signaling connection (e.g., event 624 of Figs. 6A and 6B).

[0107] Referring next to Fig. 9, another UE method 900 can be implemented in a suitable UE and includes determining whether to stop and restart the timer based on whether the UE receives a downlink message during the timer duration. For clarity, the method 900 is discussed with reference to the base station 104, the CN 110, the UE 102, and the satellite 304.

[0108] At block 902, the UE 102 establishes a signaling connection with a CN 110 via a RAN 105 as described above at block 802 with regard to Fig. 8. As such, any implementations as described with regard to block 802 may apply to block 902. At block 904, the UE 102 receives a downlink message from the CN 110 via the RAN 105 (e.g., event 608 of Figs. 6A and 6B). The downlink message includes signaling connection management information as described above with regard to Figs. 6A and 6B.

[0109] At block 906, the UE 102 determines a timer value based on the signaling connection management information as described above with regard to block 810 of Fig. 8. Similarly, at block 908, the UE 102 starts a timer according to the determined timer value as described above with regard to block 812 of Fig. 8. Therefore, any implementations as described with regard to blocks 810 and/or 812 may apply to blocks 906 and/or 908, respectively. [0110] At block 910, the UE 102 determines whether the UE 102 receives a downlink message while the timer started at block 908 is running (e.g., event 614/618/680 of Figs. 6A and 6B). Depending on the implementation, the downlink message may be or include a message to update UE NTN parameters in preparation for the UE 102 to exit coverage of the NTN (e.g., events 525C/535C, 525D, 525E, etc. of Figs. 5C-5E). If the UE 102 does receive a downlink message, then flow proceeds to the loop initiating at block 912. Otherwise, flow eventually proceeds to block 916.

[0111] The UE stops the timer at block 912 (e.g., event 616/680 of Figs. 6A and 6B) and processes the downlink message at block 914. Flow then returns to block 908 and the UE restarts the timer (e.g., event 620 of Figs. 6A and 6B). In some implementations, flow proceeds from block 914 to block 915 before returning to block 908. At block 915, the UE 102 determines a new timer value based on the downlink message. For example, in some implementations the downlink message includes a new value for a timer duration the UE 102 should use to restart the timer, a value by which the UE 102 should modify a default value for the timer, a value by which the UE 102 should modify the timer’s current value, an indication to resume the timer from the point at which the UE 102 paused it, an indication to select a different timer, etc. As such, depending on the implementation, the UE 102 may restart the timer according to a default value (e.g., if the downlink message has no signaling connection management information), according to the timer value determined at block 906, or according to a timer value based on the contents of the downlink message (e.g., a new timer value).

[0112] In other implementations, the CN 110 determines that the UE 102 is approaching the out-of-coverage boundary for the NTN and sends a downlink message to alter and/or forcibly stop the timer and release the NAS signaling connection, as illustrated herein with regard to Figs. 6B and 10.

[0113] At blocks 916 and 918, the UE 102 detects that the timer expires and releases the signaling connection in response to the timer expiration, respectively, as described above with regard to blocks 820 and 822 of Fig. 8. It will be understood that, in some implementations, the UE 102 may instead receive an RRC release message and subsequently stop the timer and release the connection, similar to blocks 818 and 822 of Fig. 8. As such, depending on the implementation, the UE 102 may perform similar actions to blocks 820 and 822 in place of blocks 916 and 918.

[0114] Referring next to Fig. 10, a CN method 1000 can be implemented in a suitable CN and includes determining whether to send a release command to a UE to force a release or to release a connection naturally (e.g., when a timer expires). For clarity, the method 1000 is discussed with reference to the base station 104, the CN 110, the UE 102, and the satellite 304.

[0115] At block 1002, the CN 110 establishes a signaling connection with a UE 102 via a RAN 105 (e.g., event 604 of Figs. 6A and 6B). In some implementations, the signaling connection is a NAS signaling connection with the CN 110 via an NTN node, such as satellite 304, of a discontinuous NTN. In further implementations, the CN 110 and the UE 102 communicate while the UE 102 is in a coverage zone for the NTN node until the CN 110 determines to release the connection.

[0116] At block 1004, the CN 110 transmits a downlink message to the UE 102 via the RAN 105 (e.g., event 608 of Figs. 6A and 6B). The downlink message includes signaling connection management information as discussed above with regard to Figs. 6A and 6B. As such, the signaling connection management information may include information such as a timer value, an amount by which to modify a default timer, an indication to use a default timer, a binary flag indicating whether to use one of two timers, etc.

[0117] In some implementations, at block 1006, the CN 110 starts a timer based on the signaling connection management information (e.g., event 613 of Figs. 6A and 6B). Depending on the implementation, the timer may be to indicate a period during which the CN 110 is to maintain the signaling connection. The CN 110 may determine the timer value by using the timer value included in the downlink message to the UE 102, by modifying a default timer value, by selecting a timer value based on a flag, etc.

[0118] After setting the timer, the UE 102 and the CN 110 eventually will plan to release the connection for the UE 102 responsive to the timer stopping. Depending on the implementation, the CN 110 may force the connection to release (e.g., as depicted in Fig. 6B above) or may allow the connection to release naturally (e.g., as depicted in Fig. 6A above). As such, at block 1007, the CN 110 determines whether to send a release command to the UE 102. If the CN 110 determines to send the release command, then flow continues to block 1008, where the CN 108 transmits a command for the UE 102 to release a connection with the CN 110 to the RAN 105 (e.g., event 628 of Fig. 6B). Then, at block 1010, the CN 110 stops the timer (e.g., event 631 of Fig.

6B). If the CN 110 determines to not send a release command, then flow continues to block 1012, where the CN 110 detects that the timer expires (e.g., event 623 of Fig. 6A). After the timer is stopped or expires, flow continues from block 1010 or block 1012 to block 1014, where the CN 110 releases the signaling connection (e.g., event 625 of Fig. 6A).

[0119] Referring next to Fig. 11 , another CN method 1100 can be implemented in a suitable CN and includes stopping a timer when an operation between the UE and the CN is to be performed. For clarity, the method 1100 is discussed with reference to the base station 104, the CN 110, the UE 102, and the satellite 304.

[0120] At block 1102, the CN 110 establishes a signaling connection with a UE 102 via a RAN 105. At block 1104, the CN 110 transmits, to the UE 102, via the RAN 105, a downlink message including signaling connection management information. Blocks 1102 and 1104 may resemble blocks 1002 and 1004, respectively, as described above with regard to Fig. 10. As such, implementations applying to blocks 1002 and/or 1004 may similarly apply to blocks 1102 and/or 1104. Similarly, at block 1106, the CN may start a timer to maintain a signaling connection based on the signaling connection management information, as described above with regard to event 1006 of Fig. 10.

[0121] At block 1107, the UE 102 and the CN 110 perform an operation via the RAN 105 while the timer is active. Depending on the implementation, the operation can be initiated by the UE 102 or the CN 110. In some implementations, the operation is a one-off exchange of information and/or messages between the UE 102 and the CN 110 via the RAN 105. In further implementations, the operation is a more involved operation (e.g., a series of exchanges, requests for handover, requests to process information, etc.). When the CN 110 initiates the operation, flow continue to block 1108. When the UE 102 initiates the operation, flow instead continues to block 1114.

[0122] At block 1108, the CN 110 determines to transmit a downlink message to the UE 102 (e.g., event 614/680 of Figs. 6A and 6B) and, at block 1110, the CN 110 then stops the timer in response to the determination (e.g., event 617/680 of Figs. 6A and 6B). The CN 110 then generates the downlink message to be transmit. In some implementations, the downlink message includes signaling connection management information to cause the timer to restart after the downlink message is transmit to the UE 102. Depending on the implementation, the signaling connection management information includes information as described elsewhere herein (e.g., a full timer value, a timer value to indicate a modification for a default timer, a timer value to function as a flag and indicate a timer, etc.). Subsequently, at block 1112, the CN 110 transmits the downlink message to the UE 102 (e.g., event 618 of Figs. 6A and 6B). If the CN 110 includes the signaling connection management information in the downlink message, the CN 110 may restart the timer (e.g. , as described at block 1106).

[0123] At block 1114, the CN 110 receives an uplink message from the UE 102 (e.g., event 614/680 of Figs. 6A and 6B) and, at block 1116, the CN 110 stops the timer in response to receiving the uplink message (e.g., event 617/680 of Figs. 6A and 6B). In some implementations, the CN 110 responds to the uplink message with a downlink message including signaling connection management information as described above. In other implementations, the CN 110 automatically starts a default timer or restarts the previous timer after receiving the uplink message.

[0124] Blocks 1107, 1108, 1110, 1112, 1114, and/or 1116 may collectively be referred to herein as Data/Signaling Communication procedure 1180, similar to Data/Signaling Communication procedure 680 described above with regard to Figs. 6A and 6B. As such, the implementations of the events comprising Data/Signaling Communication procedure 680 similarly apply to the blocks comprising Data/Signaling Communication procedure 1180. [0125] Referring next to Fig. 12, a UE method 1200 can be implemented in a suitable UE and includes determining, after a backoff timer expires, whether to attempt to access an NTN based on whether the UE is in coverage of an NTN node. For clarity, the method 1200 is discussed with reference to the base station 104, the CN 110, the UE 102, the satellite 304, and the satellite 306.

[0126] At block 1202, the UE 102 receives a downlink message from the CN 110 via an NTN node (e.g., satellite 304 as part of RAN 105), including a backoff timer value as described above with regard to Fig. 7 (e.g., event 712 of Fig. 7). At block 1204, the UE 102 starts a backoff timer using the backoff timer value (e.g., event 714 of Fig. 7). In particular, the UE 102 starts the backoff time such that, at block 1206, the UE 102 refrains from accessing the NTN while the backoff timer is running. Depending on the implementation, the UE 102 may start the backoff timer using the backoff timer value according to various methods. For example, in some implementations, the UE 102 starts the backoff timer directly using the backoff timer value (e.g., such that the length of the backoff timer is the backoff timer value). In further implementations, the UE 102 starts the backoff timer by modifying a default timer according to the backoff timer value. In still further implementations, the backoff timer value is a binary flag, and the UE 102 selects one of multiple timers based on the backoff timer value.

[0127] At block 1208, the UE 102 determines that the UE 102 is out of a coverage zone associated with the NTN node while the backoff timer is running (e.g., event 732 of Fig. 7). In some implementations, the UE 102 determines that the UE 102 is out of a coverage zone based on ephemeris information (e.g., detailing the expected positioning and/or location information for the satellite 304). In further implementations, the UE 102 determines that the UE 102 is out of a coverage zone based on the UE 102 location information. The UE 102 may further make such a determination as otherwise described herein, particularly with regard to Fig. 7 above. Then, in some implementations, at block 1210, the UE 102 stops performing one or more idle mode tasks in response to the determination. Depending on the implementation, the idle mode tasks include accessing ephemeris information, transitioning to an active mode, paging updates to the CN 110 (e.g., small data or early data transmissions), camping on a cell, etc.

[0128] At block 1212, the UE 102 detects that the backoff timer expires (e.g., event 734 of Fig. 7). Once the backoff timer expires, the UE 102 evaluates whether to attempt accessing the NTN again. In particular, at block 1214, the UE 102 determines whether the UE 102 is in a coverage zone associated with a node of the NTN, such as the satellite 306 (e.g., event 734 of Fig. 7). In various implementations, the UE 102 makes the determination according to similar factors as determining that the UE 102 is out of a coverage zone, such as those described at block 1208 above. If the UE 102 is in a coverage zone, then the flow continues to block 1216. Otherwise, flow continues instead to block 1220, where the UE 102 refrains from performing an idle mode task, and block 1222, where the UE 102 refrains from accessing the NTN.

[0129] At block 1216, the UE 102 starts performing an idle mode task. In some implementations, the idle mode task is the same task previously stopped at block 1210. In further implementations, the idle mode task is a different task with more priority. In still further implementations, the idle mode task is a different task regardless of the priority. At block 1218, the UE 102 accesses the NTN (e.g., event 736 of Fig. 7). Depending on the implementation, the UE 102 may access the NTN as part of the idle mode task started at block 1216.

[0130] Referring next to Fig. 13, a CN method 1300 can be implemented in a suitable CN and includes estimating a time for a UE to leave a coverage zone for the NTN and determining a backoff timer value based on the estimation. For clarity, the method 1300 is discussed with reference to the base station 104, the CN 110, the UE 102, and the satellite 304.

[0131] At block 1302, the CN 110 receives an uplink message from the UE 102 via an NTN node, such as satellite 304 (e.g., event 706 of Fig. 7). Depending on the implementation, the uplink message may be a service request message, a tracking area update request message, a registration request message, etc. [0132] At block 1304, the CN 110 estimates when the UE 102 will leave a coverage zone associated with the NTN node (e.g., event 708 of Fig. 7). In some implementations, the CN 110 generates the estimation of when the UE 102 is out of a coverage zone based on ephemeris information (e.g., detailing the expected positioning and/or location information for the satellite 304). In further implementations, the CN 110 generates the estimation based on the UE 102 location information. The CN 110 may further make such a determination as otherwise described herein, particularly with regard to Fig. 7 above. At block 1306, the CN 110 determines a backoff timer value based on the estimation (e.g., event 710 of Fig. 7). For example, in some implementations, the CN 110 determines the backoff timer value to match the estimation. In further implementations, the CN 110 modifies the backoff timer value by a predetermined, determined, or received margin.

[0133] At block 1308, the CN 110 includes the backoff timer value in a downlink message. Similarly, at block 1310, the CN 110 may additionally include NTN related parameters for the UE 102 in the downlink message. In some implementations, the CN 110 determines whether to include the NTN related parameters as described in more detail below with regard to Fig. 14. Depending on the implementation, the NTN related parameters include any or all of power saving parameters, NTN coverage information, or parameters related to UE mobility in the NTN. At block 1312, the CN 110 transmits the downlink message to the UE 102 (e.g., event 712 of Fig. 7).

[0134] Referring next to Fig. 14, a CN method 1400 can be implemented in a suitable CN and includes determining whether to include NTN related parameters in a message to the UE based on whether the UE will leave a coverage zone for the NTN soon. For clarity, the method 1400 is discussed with reference to the base station 104, the CN 110, the UE 102, and the satellite 304.

[0135] At block 1402, the CN 110 receives a first message from a UE 102 via an NTN node in a RAN 105, such as satellite 304 (e.g., event 606/614 or 706 of Figs. 6A- 7). Depending on the implementation, the uplink message may be a service request message, a tracking area update request message, a registration request message, etc. At block 1404, the CN 110 determines to transmit a downlink message to the UE 102 in response to the first message.

[0136] At block 1406, the CN 110 estimates a remaining time interval during which the UE 102 is in a coverage zone associated with the NTN node, similar to block 1304 of Fig. 13 above. As such, implementations described with regard to block 1304 similarly apply to block 1406. At block 1408, the CN 110 determines if the estimated remaining time is larger than a predetermined threshold. Depending on the implementation, the predetermined threshold may be a predetermined value at the CN 110 for NTN nodes generally, a predetermined value according to ephemeris information from a particular NTN node, a predetermined value according to information from a particular UE (e.g., UE 102), etc. If the estimated remaining time is larger than the threshold value, then flow continues to block 1412. Otherwise, flow continues to block 1410.

[0137] At block 1410, the CN 110 includes NTN related parameters for the UE 102 in the downlink message. Depending on the implementation, the NTN related parameters for the UE 102 may include parameters such as power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value for a power saving mode, on duration, off duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of a satellite 304 or 306 associated with the NTN, updated coverage map, etc.), and parameters related to UE mobility in the NTN (e.g., updated tracking area identity (TAI) list, parameters indicating terrestrial or NTN cell changes, etc.).

Depending on the implementation, the CN 110 may determine to include some NTN parameters but not others (e.g., based on priority, importance, time sensitivity, etc.). At block 1412, the CN 110 transmits the downlink message to the UE 102 (e.g., event 608/618/680 or 712 of Figs. 6A-7).

[0138] Referring next to Fig. 15, a UE method 1500 can be implemented in a suitable UE and includes receiving signaling management information from a CN and generating a timer for a transition into an idle mode based on the received information. For clarity, the method 1500 is discussed with reference to the base station 104, the CN 110, the UE 102, and the satellite 304.

[0139] At block 1502, the UE 102 transmits to a CN 110 via a base station 104 associated with an NTN (e.g., such as satellite 304 acting as a base station 104 for RAN 105), an uplink message (e.g., event 706 of Fig. 7). At block 1504, the UE 102 receives, via the base station 104 and responsive to transmitting the uplink message to the CN 110, a downlink message including an indication of a timer value for an out-of- coverage period associated with a node of the NTN (e.g., events 712 and 1202 of Figs. 7 and 12). At block 1506, the UE 102 starts a timer with a duration which is based on the indication and, at block 1508, the UE 102 uses the timer to control when the UE 102 attempts to detect a cell associated with the node of the NTN (e.g., events 714 and 1204 of Figs. 7 and 12).

[0140] Referring next to Fig. 16, a CN method 1600 can be implemented in a suitable CN and includes transmitting signaling management information to a UE and starting a timer for a transition into an idle mode based on the transmitted information. For clarity, the method 1600 is discussed with reference to the base station 104, the CN 110, the UE 102, and the satellite 304.

[0141] At block 1602, the CN 110 receives from a UE 102 via a base station 104 associated with an NTN (e.g., satellite 304 acting as base station 104 for RAN 105), an uplink message from a UE 102 (e.g., events 706, 1302, and 1402 of Figs. 7, 13, and 14). At block 1604, the CN 110 transmits to the UE 102 via the base station 104 and responsive to receiving the uplink message, a downlink message including an indication of a timer value for a timer representative of an out-of-coverage period associated with a node of the NTN (e.g., events 712, 1308/1312, and 1404/1412 of Figs. 7, 13, and 14).

[0142] The following description may be applied to the description above.

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

[0144] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a mediastreaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general- purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

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

Claims

WHAT IS CLAIMED IS:

1. A wireless communication method (1500) performed by a user equipment, UE, (102) connected to a core network, CN, device (110) via a non-terrestrial network, NTN (105), the method comprising: transmitting (1502), to the CN device via the NTN, an uplink message; receiving (1504), from the CN device via the NTN and responsive to the transmitting of the uplink message, a downlink message including a timer indication corresponding to an out-of-NTN-coverage period of the UE; and starting (1506) a timer according to the timer indication; and using (1508) the timer to control when the UE attempts to detect a cell associated with the NTN.

2. The wireless communication method of claim 1 , wherein the timer indication includes a timer value input to the timer or a quantity by which to adjust a default timer value input to the timer.

3. The wireless communication method of claim 1 , wherein the timer indication specifies which of a plurality of durations to input to the timer.

4. The wireless communication method of any one of claims 1-3, wherein the UE is in idle mode when performing the transmitting, and the using of the timer includes refraining from attempting to reconneOct to the CN device via the NTN while the timer is running.

5. The wireless communication method of any one of claims 1-4, wherein the downlink message includes NTN communication parameters for the UE, the NTN communication parameters including at least one of:

(i) UE power parameters;

(ii) NTN coverage parameters; or

(iii) UE mobility parameters.

6. The wireless communication method of any of claims 1 -5, the method further comprising: prior to starting the timer, performing a portion of an idle mode procedure, during which the UE communicates with the NTN in an idle mode of a protocol for controlling radio resources; pausing the idle mode procedure in response to starting the timer; and resuming the idle mode procedure in response to detecting that the timer expires.

7. The method of any one of claims 1-6, the method further comprising: after the timer expires and when the UE is within a coverage of the NTN, transmitting an uplink non-access stratum (NAS) message to the CN device.

8. A user equipment (102) comprising a transmitter (156), a receiver (154) and a processor (152), which is configured to perform a wireless communication method (1500) according to any one of claims 1 to 7 using the transmitter and the receiver.

9. A wireless communication method (1600) performed by a core network, CN, device (110) communicating with a user equipment, UE, (102) via a non-terrestrial network, NTN (105), the method comprising: receiving (1602), from the UE via the NTN, an uplink message; and transmitting (1604), to the UE via the NTN and responsive to the receiving of the uplink message, a downlink message including a timer indication corresponding to an out-of-NTN-coverage period of the UE.

10. The wireless communication method of claim 9, the method further comprising: estimating a duration of the out-of-NTN-coverage period of the UE, wherein the timer indication is based on the estimated duration.

11 . The wireless communication method of any of claims 9 or 10, wherein the timer indication is a timer value or a quantity by which the UE adjusts a default timer value.

12. The wireless communication method of any of claims 9 or 10, wherein the timer indication specifies which of a plurality of timer values to use.

13. The wireless communication method of any of claims 9 to 12, wherein the downlink message is a downlink non-access stratum (NAS) message that includes NTN communication parameters for the UE, the NTN communication parameters including at least one of:

(i) UE power parameters;

(ii) NTN coverage parameters; or

(iii) UE mobility parameters.

14. The wireless communication method of claim 13, wherein the downlink message includes the NTN communication parameters responsive to determining that a time interval until the out-of-NTN-coverage period of the UE is less than a predetermined time threshold.

15. A core network, CN, device (110) comprising a transmitter (146), a receiver (144) and a processor (142), which is configured to perform a wireless communication method (1600) according to any one of claims 9 to 14 using the transmitter and the receiver.