Managing non-access stratum signaling connections and discontinuous coverage using timers for entering idle mode

Abstract

A user equipment (102) communicating with a core network node (110) via a non-terrestrial network (105) performs a method of managing network signaling during discontinuous coverage. The method comprises: (i) receiving (806) a downlink message comprising signaling management information from the CN via the NTN; (ii) starting (812, 814) a timer, the timer having a duration determined based on the signaling management information; and (iii) using (818, 820) a timer to control when the UE transitions (822) to an idle mode by releasing a signaling connection between the UE and the CN node.

Description

Technical Field

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

[0002] This background description is provided for the purpose of generally presenting the context of the technology described in the detailed description section. The work of the presently named inventors, to the extent that it is described in this background section, and aspects of this description that may not be identified as prior art at the time of filing, are not admitted, either explicitly or implicitly, to be prior art to the present disclosure.

[0003] Fifth-generation (5G) technology primarily relies on legacy terrestrial networks. However, the 3GPP organization has proposed extending 5G communications to non-terrestrial networks (NTNs) using 5G New Radio (NR) technology or Long-Term Evolution (LTE) technology tailored for narrowband Internet of Things (NB-IoT) or enhanced machine-type communications (eMTC) scenarios. In an NTN, RF transceivers are mounted on satellites, unmanned aerial systems (UAS) (also known as drones, balloons, or aircraft), or another suitable device. For simplicity, the following discussion will refer to all such devices as satellites. In addition to satellites, an NTN also includes one or more satellite gateways connecting the NTN to public data networks, feeder links between the satellite gateways and satellites, service links between satellites, and inter-satellite links (ISLs) when the satellites form a constellation.

[0004] Satellites can be classified into one of several categories based on altitude, orbit, and beam footprint size. These include low Earth orbit (LEO) satellites, medium Earth orbit (MEO) satellites, geostationary Earth orbit (GEO) satellites, UAS platforms (including high altitude platform stations (HAPS)), and highly elliptical orbit (HEO) satellites. GEO satellites are also known as geosynchronous orbit (GSO) satellites, and LEO / MEO satellites are also known as non-GSO (NGSO) satellites.

[0005] GSO satellites can communicate with one or more satellite gateways deployed over the satellite's target coverage area (e.g., region, country, continent, etc.). Non-GSO satellites can communicate with one or more serving satellite gateways at different times. The NTN is designed to ensure service and feeder link continuity between consecutive serving satellite gateways, while also providing sufficient duration for mobile anchoring and handover procedures.

[0006] Satellites can support either transparent or regenerative (with onboard processing) payloads and typically generate several beams for a given service area defined by a field of view. The beam's footprint is typically elliptical and depends on the onboard antenna configuration and elevation angle. For transparent payload implementations, the satellite can apply RF filtering and / or frequency conversion and amplification without altering the waveform signal. For regenerative payload implementations, the satellite can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and / or encoding / decoding / modulation. This approach effectively implements most of the functionality of a base station (e.g., gNB or eNB).

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

[0008] After the UE registers with the core network (CN), the CN node manages the 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 to transition to CM connected mode. During the UE's transition to CM connected mode, the CN node updates the UE parameters during the registration or tracking process by including the updated parameters in the 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 (wherein the UE has an active radio connection with a base station), and when the CN determines that it should release the NAS signaling connection, the CN notifies the UE accordingly. In response, the UE starts a NAS timer (e.g., T3440 or T3540). The UE does not fully release the CM connection until the timer expires. The UE locally releases the established NAS signaling connection when the timer expires.

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

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

[0011] Furthermore, the UE may not be aware of NTN coverage or have the ability to estimate when the UE will leave NTN coverage. Even when the UE has such capability, the accuracy of such estimation may be poor. In such cases, the UE may attempt to access the CN using an initial NAS procedure before leaving NTN coverage for the transition from CM Idle Mode to CM Connected Mode. If the CN node accepts the initial NAS procedure, the UE may only be in coverage for a short period of time. Therefore, the above-mentioned discontinuous coverage scenario causes unnecessary transitions between CM Idle Mode and CM Connected Mode, which similarly leads to inefficient use of radio resources and UE battery power. In addition, existing CN timers may be stopped, reset, or otherwise modified by terrestrial network interactions between the CN and the UE, making such timers unsuitable for maintaining alignment with NTN coverage. Summary of the Invention

[0012] When communicating with a CN via an NTN, the UE manages network signaling during periods of discontinuous coverage. The UE transmits an uplink message to the CN via the NTN. The UE then receives a downlink message from the CN, including signaling management information, via the NTN in response to the uplink message transmitted to the CN. The UE then starts a timer with a duration determined based on the signaling management information and uses the timer to control when the UE transitions to idle mode, which is associated with a protocol for controlling signal management in anticipation of an upcoming period outside of NTN coverage.

[0013] The CN node, communicating with the UE via the NTN, similarly manages network signaling during the UE's discontinuous coverage period. The CN node transmits a downlink message including signaling management information to the UE via the NTN. The CN node then starts a timer with a duration indicated in the first signaling management information, which takes into account the UE's upcoming period outside of NTN coverage. The CN node uses the timer to assess when the UE switches from connected mode to idle mode, which is associated with a protocol for control signal management. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 2 It shows that Figure 1 A block diagram of a protocol stack used by a UE to communicate with a base station therein;

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

[0017] Figure 3B is a block diagram illustrating an NTN node with a transparent payload implementation, wherein a base station is connected to multiple satellites via the same satellite gateway;

[0018] Figure 4A Shows that Figure 3A User plane protocol stack used with the architecture;

[0019] Figure 4B Shows that Figure 3A The control plane protocol stack used in conjunction with the architecture;

[0020] Figure 5A shows a scenario where the UE has satellite coverage during certain time periods separated by non-coverage intervals;

[0021] Figure 5B Shows a conventional scenario where the UE releases the NAS connection after the timer expires;

[0022] Figure 5C Another conventional scenario is shown, where the UE and CN enter the CM Connected state from the CM Idle state within a short period before the UE's NTN out-of-coverage period to update parameters and then release the NAS connection;

[0023] Figure 5D Shown with Figure 5C A similar scenario to that in

[15] , but where the UE and CN use timers to indicate when to release the NAS connection, resulting in fewer changes between the CM idle state and the CM connected state;

[0024] Figure 5E Shown with Figure 5D Another scenario similar to the scenario in , but where the CN causes the UE to release the NAS connection before the timer expires;

[0025] Figure 5F Yet another conventional scenario is shown, where the CN rejects a connection request from a UE shortly before the UE is out of NTN coverage, and the UE subsequently attempts to resend the request while in an out-of-coverage period of the NTN;

[0026] Figure 5G Shows something like Figure 5F Scenario 2, but where the CN includes a backoff timer indication in the rejection and the UE avoids attempting to resend the request until the timer expires;

[0027] Figure 6A is a message passing diagram for a scenario according to an embodiment, wherein the CN provides timer information to the UE to start a timer after which the UE will release the connection to the CN;

[0028] Figure 6B is another message passing diagram according to another embodiment, wherein the CN interrupts the timer with a resource release command;

[0029] Figure 7 is yet another messaging diagram according to an embodiment, wherein the CN determines when the UE leaves NTN coverage and a time interval during which the UE does not attempt to connect with the CN via the NTN;

[0030] Figure 8 According to an embodiment, the method for determining whether to start Figure 6A and Figure 6B Flowchart of a UE method for using a timer as described in claim 1, wherein the timer has a default value or a timer value inferred based on a downlink message;

[0031] Figure 9is a flow chart of another UE method according to an embodiment for stopping and restarting a downlink message based on whether the UE receives another downlink message while a timer is running. Figure 6A and Figure 6B The timer described;

[0032] Figure 10 is a flow chart of a CN method for releasing a connection between a UE and a CN when a CN timer expires according to an embodiment;

[0033] Figure 11 is a flow chart of a CN method for pausing a timer when message transfer occurs between a UE and a CN via an NTN node according to an embodiment;

[0034] Figure 12 is for use according to an embodiment as described with respect to Figure 7 A flowchart of a UE method for determining when to access an NTN node using a backoff timer as described;

[0035] Figure 13 According to an embodiment, a method for transmitting Figure 7 A flowchart of a CN method for transmitting a downlink message of a backoff timer value as described in;

[0036] Figure 14 is a flow chart 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 during which a UE remains in a coverage area of ​​an NTN node is greater than a threshold value according to an embodiment;

[0037] Figure 15 is a flow chart of a UE method for managing network signaling during discontinuous coverage according to an embodiment; and

[0038] Figure 16 is a flow chart 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) may use the techniques of this disclosure to manage early data communications and to transition the UE between states of a protocol for controlling radio resources between the UE and the RAN.

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

[0041] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, cell 124 is an NR cell. If base station 104 is an ng-eNB or an eNB, cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, cell 126 is an NR cell, and if base station 106 is an ng-eNB or an eNB, cell 126 is an E-UTRA cell. Cells 124 and 126 may be located in the same radio access network notification area (RNA) or in different RNAs. In general, RAN 105 may include any number of terrestrial and non-terrestrial base stations, and each of the base stations may cover one, two, three, or any other suitable number of cells. UE 102 may support at least 5G NR (or simply "NR") or E-UTRA air interface to communicate with base stations 104 and 106. Each of the base stations 104, 106 is connected to the CN 110 via an interface (e.g., an S1 or NG interface). The base stations 104 and 106 may also be interconnected via an interface for interconnecting NG RAN nodes (e.g., an X2 or Xn interface).

[0042] Among other components, the EPC 111 may also include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. The SGW 112 is generally configured to deliver user plane packets associated with 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, an access and mobility management function (AMF) 164, and / or a session management function (SMF) 166. Generally speaking, UPF 162 is configured to deliver user plane packets associated with audio calls, video calls, internet traffic, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0043] like Figure 1As shown, base station 104 supports cell 124, and base station 106 supports cell 126. Cells 124 and 126 may partially overlap, allowing UE 102 to select, reselect, or switch from one of cells 124 and 126 to the other. To exchange messages or information directly, base station 104 and base station 106 may support an X2 or Xn interface. In general, CN 110 may be connected to any suitable number of terrestrial base stations and / or non-terrestrial base stations that support 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 is operating in an inactive or idle state of a protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examples below relate to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol.

[0045] The base station 104 is equipped with a transceiver and processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware 130 may include a dedicated processing unit. In an example implementation, the processing hardware 130 includes a processor 132 to process data to be transmitted by the base station 104 in the downlink direction, or to process data received by the base station 104 in the uplink direction. The processing hardware 130 may also include a transmitter 136 configured to transmit data in the downlink direction. The processing hardware may further include a receiver 134 configured to receive data in the uplink direction. The processing hardware may further include an RRC controller 138 to implement processes and message passing at the RRC sublayer of the protocol communication stack. The base station 106 may include substantially similar components. The CN node 110 , which hosts and executes one or more of the modules and functions described above, includes components 140 , 142 , 144 , 146 , and 148 , which are similar to components 130 , 132 , 134 , 136 , and 138 , respectively.

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

[0047] Figure 2 A protocol stack 200 is shown in a simplified manner, according to which the UE 102 can communicate with an eNB / ng-eNB or 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, the EUTRA physical layer (PHY) 202A 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 the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRRPHY 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 delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data delivery services to the Service Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer ( Figure 2 In some implementations, UE 102 supports the following: Figure 2 Both EUTRA and NR stacks are shown to support switching between EUTRA and NR base stations and / or support DC through EUTRA and NR interfaces. Figure 2 As shown, the UE 102 can support the layering of the NR PDCP 210 on the EUTRA RLC 206A and the layering of the SDAP sublayer 212 on the NR PDCP sublayer 210.

[0049] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which may be referred to as service data units (SDUs) (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on the PDCP layer 208 or 210), and output packets, which may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure refers to both SDUs and PDUs as "packets," except where the distinction between SDUs and PDUs is relevant.

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

[0051] Figure 3A A certain type of NTN deployment, known as a transparent payload architecture, is shown. This NTN deployment involves a satellite gateway 302 and a "transparent" satellite 304, used to extend the range of the Uu interface. Satellite 304 implements frequency conversion and radio frequency (RF) amplification in both the uplink and downlink directions. The satellite functions similarly to an analog RF repeater. Thus, satellite 304 relays the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the serving 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 Uu, and the NTN gateway 302 supports all necessary functions for forwarding signals of the Uu interface. The NTN gateway 302 can be placed at the same location as a base station (e.g., eNB, gNB) 104, or connected to the base station 104 at a distance via a wired link. More than one NTN gateway can also be connected to a base station. Different transparent satellites can be connected to the same base station on the ground via the same NTN gateway or via different NTN gateways.

[0052] Figure 3B An implementation is shown where two different satellites (304 and 306) are connected to the same base station 104 via the same NTN gateway 302 and the two satellites (304 and 306) cover the Earth's surface using two different physical cell IDs (PCIs).

[0053] Next, Figure 4AThe NTN user plane protocol stack 400A involving UE 102, satellite 304, NTN gateway 302, base station 104 and EPC S-GW 112 (or 5GC SMF 166) is shown. The NTN user plane protocol stack is similar to the protocol stack of the terrestrial network (TN), except that Figure 4A The configuration of FIG. 3 shows two additional nodes (satellite 304 and NTN gateway 302) operating in the middle of the Uu interface. Figure 4A The 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 the 5GC AMF 164) is shown. Similar to the NTN user plane protocol stack 400A, Figure 4B The NTN control plane protocol stack 400B shown in FIG is also substantially similar to Figure 2 The protocol stack of the TN counterpart is shown.

[0054] Overall reference Figures 1 to 4B , NTN supports at least three types of service links NTN described according to the satellite mobility pattern: (i) Geofixed: provided by a beam that always continuously covers the same geographical area (e.g., the case of GEO / GSO satellites); (ii) Quasi-Geofixed: provided by a beam that covers one geographical area for a limited period of time and a different geographical area during another period of time (e.g., the case of LEO / MEO satellites capable of using steerable beams); and (iii) Geomobile: provided by a beam whose coverage area slides above the surface of the Earth (e.g., the case of LEO / MEO satellites using fixed or non-steerable beams).

[0055] Using LEO / MEO satellites, the base station can provide quasi-Earth fixed cell coverage or Earth mobile cell coverage. Using GEO satellites, the base station can provide Earth fixed cell coverage.

[0056] although Figure 3A and Figure 3B The transparent payload architecture shown is currently the focus of 3GPP development, but a regenerative payload architecture, which places some base station functionality on the satellite, is also a possible future NTN deployment. In this architecture, the Uu exists only between the satellite and the UE. In general, the techniques disclosed herein are applicable to both transparent and regenerative payload architectures.

[0057] Again, overall reference Figures 1 to 4A, a UE 102 operating in a certain cell must be able to detect reference signals from neighboring cells and measure the strength of the reference signals in order to be able to switch to a qualified neighboring cell when needed (i.e., when the serving cell can no longer serve the UE due to poor signal reachability) or in order to add a new carrier component (CC). The reference signals that the base station can use for this purpose in conjunction with the NR radio interface are the synchronization signal (SS) and the physical broadcast channel (PBCH) block (abbreviated as SSB). Unlike the LTE radio interface in which the base station transmits an SS every 5 ms, 5G NR allows each base station to transmit SSB bursts in a different time pattern with a maximum periodicity of up to 160 ms. This allows the network to configure the SSB transmission in a more dynamic way according to actual usage and channel conditions.

[0058] This approach helps avoid unnecessary measurements and reduces UE power consumption. However, this flexibility comes at the expense of additional signaling to inform the UE when to perform measurements on the measurement target. Without additional signaling, the UE would need to assume a worst-case scenario (5 ms periodicity in the above implementation) to determine when to measure the target. Therefore, the UE does not achieve any power saving gains. This additional signaling in 5G NR is called "SSB-based Measurement Timing Configuration (SMTC)" and it contains periodicity settings ranging from 5 ms to 160 ms and duration settings 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 example, the SMTC periodicity can be set to a value greater than the SSB burst periodicity to further reduce the UE's power consumption. In addition to the periodicity and duration settings, the SMTC also indicates a timing offset to inform the UE of the exact subframe in which the UE should start monitoring for an SSB burst that recurs according to the periodicity setting. The base station can signal the periodicity and timing offset settings together as a single parameter, periodicityAndOffset, in one measurement object.

[0060] There may be relatively small timing differences between the timing of the primary cell (PCell) and the timing of the measurement target, which is partly due to propagation delay differences. Terrestrial networks can ignore this small timing difference because the propagation delay differences are small and therefore do not need to adjust the timing offset setting. Therefore, 3GPP TS 38.331 (v16.6.0) currently specifies only one timing offset for measurement object configuration. However, for non-terrestrial networks, the propagation delay between the satellite and the UE can be longer (e.g., up to 25.77 ms), and the difference between different satellites can be large (e.g., between 8 ms and 25.77 ms).

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

[0062] Figure 5A Scenario 500A is shown in which a UE 102 may experience discontinuous coverage from an NTN due to, for example, a sparse satellite constellation deployment. In scenario 500A, the UE 102 is within a first coverage area 314 served by a LEO satellite 304 from t1 to t2 and within a second coverage area 316 served by another LEO satellite 306 from t3 to t4. However, during the period between t2 and t3, the UE 102 is not served by any satellite or any ground base station and is therefore outside the coverage area of ​​the NTN node. Typically, when a UE 102 loses coverage of a serving cell, the UE 102 begins searching for other cells and then camps on a suitable cell. However, in Figure 5A In the example shown, even if UE 102 starts searching for other cells immediately after t2, UE 102 cannot find a cell. Furthermore, depending on the implementation, the cell search can last for a long time, as the time period between t2 and t3 can vary from tens of minutes to several hours. Therefore, the cell search results in additional, unnecessary power consumption in UE 102.

[0063] In order to Figure 5A In order to reduce power consumption at the UE in the scenario depicted in FIG, the UE 102 may not need to perform a cell search and may deactivate access stratum (AS) functionality during periods when the UE is not within the coverage area of ​​a satellite. In some implementations, the UE 102 understands when the UE 102 will be outside the coverage area and when the UE 102 will be within the coverage area again, so that the cell search or AS functionality can be reactivated before the UE 102 falls into the coverage of another NTN cell. For example, ephemeris information broadcast in system information provides constellations and trajectory or movement information of nearby satellites (e.g., serving satellites and neighboring satellites), which helps the UE 102 estimate when the UE 102 will be inside or outside the NTN coverage. In addition to ephemeris information, the UE 102 may also use other information to more accurately estimate the coverage of the NTN cell.

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

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

[0066] Figure 5C 5. The conventional operation that results in undesirably high power consumption is shown. Specifically, the CN 110 enters 505C idle mode and notifies 510C the NAS signaling connection release to the UE 102 (e.g., causing the UE 102 to enter CM idle mode). The UE 102 activates a timer 590C (e.g., the T3440 / T3450 timer described above), and after the timer 590C expires, the UE 102 releases 550C the NAS signaling connection and enters CM idle mode 527C (the CN simultaneously assumes 526C that 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 scenario discussed herein, the CN 110 may need to update parameters related to the NTN. In various implementations, the NTN parameters may include any one or all of the following: power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value of power saving mode, on duration, off duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of satellites 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 identifier (TAI) list, parameters indicating terrestrial or NTN cell change, etc.). However, the CN 110 may update the parameters related to the NTN after the UE 102 has released 550C NAS signaling connection (e.g., in the above discussion of Figure 5B 102) attempts to update the NTN related parameters of the UE 102. Therefore, when the CN 110 detects 525C that the UE 102 is about to leave the NTN coverage area (e.g., Figure 5A When the UE 102 reaches the coverage area 314 in the 5GS, the CN pages (i.e., sends a paging message to) the UE to transition to connected mode. Consequently, UE 102 receives 520C the paging message and transitions to connected CM mode 527C. CN 110 updates 535C parameters (e.g., using TAU for EPS and registration or RNAU procedures for 5GS) and releases the connection, thereby returning to CM idle mode. Similarly, UE 102 releases 530C the connection and returns to CM idle mode.

[0068] Scenario 500C, in which UE 102 is connected to CN 110 via an NTN with discontinuous coverage, requires additional transitions between idle mode and connected mode, which wastes UE radio resources and battery power. By introducing a new timer when CN 110 is releasing the connection with UE 102, UE 102 avoids such waste while minimizing the time spent active in discontinuous coverage periods, thereby improving UE 102's power, resource usage, and overall operation.

[0069] Figure 5D Scenario 500D is shown, which is similar to scenario 500C, but in which UE 102 and CN 110 use timers to indicate when to release the NAS connection, thereby making the change between the CM idle state and the CM connected state less. Specifically, when CN 110 determines 505D to enter idle mode and notifies 510D NAS signaling connection release to UE 102, CN 110 includes a timer value and / or indication, as described below with respect to Figure 6A and Figure 6B500D . As described in more detail. UE 102 starts a NAS release timer 595D, and CN 110 starts a NAS release timer 596D with a similar or identical value. Then, when the network detects that UE 102 is about to leave NTN coverage, CN 110 updates the parameters of UE 102, which UE 102 receives 520D while remaining in connected mode, thereby eliminating the additional transitions to and from connected mode in scenario 500C. In some implementations, UE 102 and CN 110 update the parameters based on a value included in a parameter message received 520D by UE 102, an initial value received 510D by UE 102 in an initial message, a default value, or as described below with respect to Figure 6A The timers then expire at 530D and 535D, respectively, causing the UE 102 and CN 110 to naturally release the CM connection, as described below with respect to Figure 6A Described in more detail.

[0070] Figure 5E Another scenario 500E is shown that is similar to scenario 500D, but in which CN 110 causes UE 102 to release the NAS connection before the timer expires. Specifically, after restarting timers 528E and 529E, CN 110 determines 535E to release the NAS connection and sends an indication to UE 102 to release 530E the connection, as described below with respect to Figure 6B Described in more detail.

[0071] Figure 5F Yet another scenario 500F is shown in which CN 110 rejects UE 102's attempt to connect to CN 110, after which UE 102 continues to attempt to connect. Specifically, UE 102 attempts 540F to connect to CN 110 (e.g., using a TAU message, a registration message, etc.). CN 110 determines that UE 102 will soon exit NTN coverage (as discussed below with respect to Figure 7 570F the attempt. UE 102 receives 570F the rejection and remains in idle mode. Later, UE 102 attempts 598F to connect to CN 110 via NTN, but is unable to because UE 102 is outside NTN coverage. Therefore, UE 102 continues to attempt to connect to CN 110 until it re-enters NTN coverage (e.g., as described above with respect to Figure 5A 306), where the UE 102 successfully connects 580F and 585F with the CN 110.

[0072] Figure 5GScenario 500G is shown, which is similar to scenario 500F, but in which CN 110 includes a backoff timer indication in the rejection, and UE 102 refrains from resending the request until the backoff timer expires. Specifically, when CN 110 rejects the connection attempt, CN 110 includes a backoff timer value, which UE 102 receives 570G and uses to generate a backoff timer 597G (e.g., as described below with respect to Figure 7 10. The UE 102 uses a backoff timer 597G and remains in an idle state until after the timer 597G expires 580G. The UE 102 then returns to coverage and connects 585G with the CN 110.

[0073] Next, refer to Figures 6A to 7 Discussions Figure 1 Several components of and several example scenarios related to detecting out of coverage in inactive or connected states. Figures 6A to 7 Similar events in the figures are labeled with the same or similar reference numerals, with differences discussed below where appropriate. Except for the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for message passing and processing) may be applied to events labeled with similar reference numerals in other figures, and may also be applied to both integrated base stations and distributed base stations.

[0074] Figure 6A Message passing diagram 600A shows UE 102 communicating with CN 110 via base station 104 including satellite 304. Message passing diagram 600A is similar to the message passing diagram described above. Figure 5D 5GCM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state or 5GMM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state or 5GMM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state or 5GMM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state or 5GMM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state or 5GMM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state or 5GMM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state. In a further embodiment, the connection state is 5GCM-CONNECTED state.

[0075] When operating in the connected state, UE 102 transmits 606 data and / or signaling to CN 110 via base station 104 (e.g., an NTN node such as satellite 304). In the following description, unless otherwise specified, any description of messages, data, and / or signaling between UE 102 and CN 110 will be interpreted as being transmitted via base station 104. After receiving 606 the data and / or signaling, CN 110 transmits 608 a NAS signaling connection release message to UE 102 to cause UE 102 to transition to the idle state. In some implementations, NAS signaling connection release message 608 includes NAS signaling connection management information for UE 102. The NAS signaling connection management information is used to notify 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 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 the NAS signaling connection release message 608. For example, when the NAS signaling connection release message 608 is a tracking area update message, the CN 110 may include a TAU timer value. In a further such implementation, the CN 110 modifies the value to be longer or shorter depending on the remaining NTN coverage time of the UE 102. In a further such implementation, the CN 110 includes a timer value, such as a TAU timer, and an amount for modifying the timer in question.

[0077] After UE 102 receives 608 the NAS signaling connection release message, UE 102 determines 610 a first timer value based on the NAS signaling connection management information and starts 612 a UE timer (i.e., a UE NAS signaling connection release timer) based on the first timer value. Similarly, after CN 110 transmits 608 the NAS signaling connection release message, CN 110 starts 613 a corresponding network timer for releasing the NAS signaling connection based on the NAS signaling connection management information with the first timer value or a timer value close to the first timer value. The network timer can be a general 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 still 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 where CN 110 does not include NAS signaling connection management information in message 608, the first timer value is a first default timer value (e.g., a default NAS signaling connection release timer value). Depending on the implementation, the UE 102 is pre-configured to store a default timer value, and the NAS signaling connection management information instructs the UE 102 to use the default timer value.

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

[0080] In a further implementation, the NAS signaling connection management information includes an offset value (e.g., 10 seconds, 20 seconds, 30 seconds, etc.) from the default timer value. 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 CN 110 estimates that UE 102 will leave coverage after a specific time period (e.g., 18 seconds). In this example, CN 110 sets the offset value to +8 seconds. In another example, the default timer value is 10 seconds, and CN 110 estimates that UE 102 will leave coverage after a specific time period (e.g., 8 seconds). In this example, CN 110 sets the offset value to -2 seconds.

[0081] In a further implementation, the NAS signaling connection management information includes a multiplier applied to the default timer value. For example, CN 110 estimates that UE 102 will leave coverage after a certain period of time and sets the multiplier to an upper limit of (period of time) / (default NAS signaling connection release timer value). When UE 102 receives the multiplier in the NAS signaling connection management information, UE 102 derives the timer value as the default timer value multiplied by the multiplier. For example, the period of time is 18 seconds, and the first default timer value is 10 seconds. In this example, CN 110 sets the multiplier to 2. Therefore, UE 102 derives the NAS signaling connection release timer value to 20 seconds, which is 10 seconds multiplied by 2.

[0082] In some implementations, the UE 102 is preconfigured with a timer value, and the NAS signaling connection management information includes an indication that the UE 102 should 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 of which timer value the UE 102 should apply. For example, the UE 102 is preconfigured with timer values ​​of 10 seconds, 15 seconds, 20 seconds, and 30 seconds. The NAS signaling connection management information includes a binary flag that distinguishes which timer value the UE 102 should select (e.g., 00 indicates a timer value of 10 seconds, 01 indicates 15 seconds, 10 indicates 20 seconds, and 11 indicates 30 seconds). In some implementations, the preconfigured timer values ​​include a timer value for another timer (e.g., timer T3440 / T3540), and one of the potential indicators is to use such a timer to determine the value.

[0083] In some implementations, the CN 110 may 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 communication between the CN 110 and the UE 102 may be mobile terminated (MT) or mobile originated (MO). The UE 102 may stop 616 the UE timer in response to the communication 614, and / or the CN 110 may stop 617 the network timer upon determining to communicate. Depending on the implementation, the CN 110 stops the timer by temporarily pausing the timer, restarting the timer (e.g., as described below in conjunction with starting 621 the timer), and / or releasing the timer (e.g., upon releasing the connection with the UE 102, as described below with respect to event 631). Figure 6B ). In some implementations, the communication 614 includes one or more downlink (DL) NAS messages (e.g., a GUTI 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 communication 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 message 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 a 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 NTN-related UE parameters include power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value of power saving mode, on-duration, off-duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of satellites 304 or 306 associated with the NTN, updated coverage maps, etc.), and parameters related to UE mobility in the NTN (e.g., updated tracking area identifier (TAI) list, parameters indicating terrestrial or NTN cell changes, etc.). In some implementations, the NTN-related UE parameters are dynamic, and thus the CN 110 generates such parameters dynamically rather than statically in advance. 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, DL NAS message 618 includes another set of NAS signaling connection management information for UE 102 to determine a second timer value for the first timer, similar to event 608. After receiving NAS signaling connection management information 618, or in response to receiving the NAS signaling connection management information, UE 102 determines a second timer value based on the NAS signaling connection management information 618 and starts or restarts 620 a UE timer with the second timer value. In implementations where DL NAS message 618 does not include another set of NAS signaling connection management information, UE 102 may start or restart a UE timer with the first timer value or a default timer value. In some implementations, after CN 110 transmits DL NAS message 618, CN 110 starts or restarts 621 a network timer with the second value or a value similar to the second value. In implementations where DL NAS message 618 does not include another set of NAS signaling connection management information, CN 110 starts a network timer with the value used or determined by CN 110 in event 613.

[0086] Events 614, 616, 617, 618, 620, and 622 Figure 6A The data / signaling communication process 680 is collectively referred to as the data / signaling communication process 680, which may be optional.

[0087] Later, UE 102 detects 622 expiration of a UE timer. Upon expiration of the UE timer, UE 102 releases 624 the NAS signaling connection and transitions 626 from the connected state to the idle state. In some implementations, the idle state is the ECM-IDLE state or the EMM-IDLE state for MME 114. In further implementations, the idle state is the 5GCM-IDLE state or the 5GMM-IDLE state for AMF 164. Similarly, later, CN 110 detects 623 expiration of a network timer. Upon expiration of the network timer, CN 110 releases 625 the NAS signaling connection and determines that the UE is operating in the idle state. In some implementations, CN 110 may transmit 628 a release command (e.g., a UE CONTEXT RELEASE COMMAND message) to base station 104, causing base station 104 to remove the UE context. In response, base station 104 releases the UE context and transmits a completion message (e.g., a UE CONTEXT RELEASE COMPLETE message) to CN 110.

[0088] In some implementations, the UE 102 applies the most recently received NAS signaling connection management information or the most recently received NAS signaling connection management information until the next tracking area update procedure or the next registration procedure. If the UE 102 does not receive the NAS signaling connection management information in the tracking area accept message or the registration accept message during the next tracking area update procedure or the next registration procedure, the UE applies the first default timer value to the UE timer. In such a case, 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] Figure 6B 6. Message transfer diagram 600B is shown in which UE 102 communicates with base station 104 of RAN 105 including satellite 304. Message transfer diagram 600B is similar to message transfer diagram 600A, except that the message exchanges and actions (e.g., events 612 / 613 and / or 620 / 621 / 680) occur after UE 102 and CN 110 start a timer for NAS signaling connection release with a first value or a second value. Message transfer diagram 600B is similar to message transfer diagram 600A described above. Figure 5E, which corresponds to scenario 500E. While the UE timer and network timer are running, CN 110 transmits a UE context release message 628 to base station 104 to initiate a signaling connection release procedure. In response, base station 104 transmits an RRC release message 629 to UE 102. Depending on the implementation, CN 110 may determine to release UE 102 due to an indication from UE 102 or base station 104 (e.g., the UE needs to immediately end the connection or reallocate radio resources), a determination by CN 110 (e.g., UE 102 will soon leave the coverage of satellite 304), an indication from another base station (e.g., a handover to base station 106), etc. In further implementations, base station 104 determines that the RRC or AS connection should be released upon expiration of a base station-specific inactivity timer. In such implementations, base station 104 causes UE 102 to end the connection without prompting from CN 110.

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

[0091] Figure 7 is another message transfer diagram 700 exchanged between the UE 102 and the CN node 110 via the base station 104 of the RAN 105 including the satellite 304 and the satellite 306. The CN 110 corresponds to the MME 114 for EPS and / or the AMF 164 for 5GS. The message transfer diagram 700 is similar to the above-described Figure 5G5. UE 102 initially operates 702 in the coverage area of ​​satellite 304. For example, UE 102 operating in an idle state 704 (e.g., the ECM-IDLE state or the EMM-IDLE state of EPS and the 5GCM-IDLE state or the 5GMM-IDLE state of 5GS) is within the coverage area of ​​satellite 304. UE 102 attempts to access CN 110 by transmitting an uplink (UL) NAS message 706 to CN 110 to transition to a connected state. 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, CN 110 checks an estimated time 708 until the UE leaves NTN coverage. This estimate is performed by CN 110 or another entity (e.g., a third-party server or application server). If the estimate is below a predefined threshold, meaning that the UE will leave NTN coverage in a short period of time, CN 110 decides to reject the initial NAS request. In some implementations, CN 110 determines 710 a backoff timer value based on estimate 708. For example, if estimate 708 indicates that UE 102 will leave coverage in approximately five minutes, CN 110 determines to prevent UE 102 from attempting to access the network by setting a backoff timer greater than five minutes. In some implementations, this estimate includes both the time until UE 102 leaves NTN coverage and the time UE 102 will remain outside NTN coverage (e.g., the estimated remaining time until the UE returns to the coverage area of ​​the next NTN node). In some such implementations, the backoff timer causes the UE 102 to avoid attempting access before and after the UE 102 leaves the coverage area, which reduces unnecessary signaling and power consumption. In some implementations, the CN 110 determines NTN-related UE parameters and provides them to the UE 102. In various implementations, the NTN-related UE parameters include, but are not limited to: power saving parameters (e.g., periodic tracking area update timer, periodic registration timer, active time value of power saving mode, on-duration, off-duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of satellites 304 or 306 associated with the NTN, updated coverage maps, 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 CN 110 decides 708 to reject UL NAS message 706 and determines 710 the backoff timer value and NTN-related UE parameters, CN 110 transmits a DL NAS message 712 to UE 102. Depending on the implementation, DL NAS message 712 is an action rejection in response to the request made by UE 102 in UL NAS message 706. Thus, in various implementations, DL NAS message 712 includes a service or tracking message for EPS (e.g., a SERVICE REJECT message or a TRACKING AREA UPDATE REJECT message) and a service or registration message for 5GS (e.g., a SERVICE REJECT message or a REGISTRATION REJECT message). DL NAS message 712 includes the EMM cause or 5GMM cause value and the backoff timer value determined in event 710. In some implementations, DL NAS message 712 also includes 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 about to leave the coverage area. 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 cell in the tracking area) or #22 (i.e., congested). 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 DL NAS message 712, UE 102 starts a backoff timer 714. In some implementations, the backoff timer is a new timer (e.g., NAS timer T34XX or T35XX) that prohibits UE 102 from attempting to access the core network until the timer expires. This new timer stops when CN 110 sends a page for any downlink signaling and / or data, or when CN 110 sends downlink signaling. This new timer also stops when UE 102 selects a cell that is not an NTN cell or selects a TN (terrestrial network) cell. In some implementations, this new timer does not stop when the core network changes (e.g., if UE 102 moves from EPS to 5GS, the timer remains running, or vice versa), and UE 102 continues to be restricted 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 a NAS timer T3440 (e.g., for EPS) or T3540 (e.g., for 5GS) and releases the connection upon expiration of the timer, causing the UE 102 to transition to the idle state 726. In some implementations, the CN 110 may send a UE CONTEXT RELEASE message 728 to the base station 104 to initiate the signaling connection release procedure, and in response, the base station 104 transmits an RRC RELEASE message 729 to the UE 102. After the UE 102 receives the RRC RELEASE message 729, the AS layer or RRC layer of the UE 102 indicates to the NAS layer that the RRC connection has been released. The NAS layer of the UE 102 considers the NAS signaling connection to be released 724, causing the UE 102 to transition to the idle state 726. After transmitting the DL NAS message 712 or after transmitting the UE CONTEXT RELEASE COMMAND message 728, the CN 110 considers the UE 102 to have entered the idle state 725. After the UE 102 detects that it is outside NTN coverage 732, the UE 102 continues to run the back-off 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 back-off timer in UE 102 expires and UE 102 detects that it is in the NTN coverage area of ​​satellite 306, if a UL NAS message 736 is still needed, UE 102 transmits the message. If 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 back-off timer stops and, if a UL NAS message 736 is still needed, transmits the message.

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

[0100] Next, refer to Figures 8 to 14Several methods are discussed that can be implemented in a UE (e.g., UE 102) or a CN node operating as an MME or performing an AMF. 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] First reference Figure 8 , UE method 800 can be implemented in a suitable UE (e.g., 102) and includes determining a value for starting a timer based on the content of the signaling management information and determining how to release the signaling connection based on whether the UE receives a release message. For clarity, method 800 is discussed with reference to RAN 105, base station 104, CN 110, UE 102, and satellite 304.

[0102] At block 802, UE 102 establishes a signaling connection with CN 110 via RAN 105 (e.g., Figure 6A and Figure 6B In some implementations, the signaling connection is a NAS signaling connection with the CN 110 via an NTN node, such as a satellite 304 of a discontinuous NTN. At block 804, the UE 102 transmits one or more messages (e.g., Figure 6A and 6B Event 606). In an implementation where the signaling connection is a NAS signaling connection via an NTN node, the message is a NAS message transmitted between UE 102 and CN 110 when UE 102 is within a coverage area associated with the NTN node.

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

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

[0105] At block 814, the UE 102 starts a timer according to a default timer value (e.g., Figure 6A and 6B 810 / 612). It should be appreciated that although block 814 specifically notes a default timer value, UE 102 may use a default timer value at block 812 based on the content of the downlink message as described with respect 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 CN 110 at an earlier time (e.g., when initially connected via RAN 105), etc.

[0106] After setting the timer, UE 102 and CN 110 will eventually plan to release the connection of UE 102 in response to the timer expiring. Depending on the implementation, CN 110 may force the connection release (e.g., as described above). Figure 6B ) or the connection may be allowed to release naturally (e.g., as described above Figure 6A Thus, at block 816, the UE 102 determines whether the UE has received an RRC release message and determines whether to force the connection release. In some such implementations, then, at block 818, the UE 102, in response to receiving the RRC release message (e.g., Figure 6B In other implementations, at block 820, the UE 102 detects that the timer has expired (e.g., Figure 6A Then, at block 822, UE 102 releases the signaling connection (e.g., Figure 6A and 6B Event 624).

[0107] Next reference Figure 9Another 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 within 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, UE 102 establishes a signaling connection with CN 110 via RAN 105, as described above with respect to Figure 8 As described at block 802. Thus, any implementation as described with respect to block 802 may be applied to block 902. At block 904, the UE 102 receives a downlink message (e.g., Figure 6A and Figure 6B Event 608). The downlink message includes the Figure 6A and Figure 6B Described signaling connection management information.

[0109] At block 906, the UE 102 determines a timer value based on the signaling connection management information, as described above with respect to Figure 8 Similarly, at block 908, UE 102 starts a timer based on the determined timer value, as described above with respect to Figure 8 Thus, any implementation as described with respect to blocks 810 and / or 812 may be applied to blocks 906 and / or 908, respectively.

[0110] At block 910, the UE 102 determines whether the UE 102 receives a downlink message (e.g., Figure 6A and Figure 6B Depending on the implementation, the downlink message may be or include a message for updating UE NTN parameters to prepare for UE 102 to exit the coverage of the NTN (e.g., Figures 5C to 5E 525C / 535C, 525D, 525E, etc.). If the UE 102 does receive a downlink message, the flow proceeds to the loop initiated at block 912. Otherwise, the flow ultimately proceeds to block 916.

[0111] The UE stops the timer at block 912 (e.g., Figure 6A and Figure 6B 616 / 680) and processes the downlink message at block 914. Flow then returns to block 908 and the UE restarts the timer (e.g., Figure 6A and 6B620 of event 620). 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 the timer duration that the UE 102 should use to restart the timer, a value for which the UE 102 should modify a default value for the timer, a value for which the UE 102 should modify a current value for the timer, an indication to resume the timer from the point at which the UE 102 suspended the timer, an indication to select a different timer, etc. Thus, depending on the implementation, the UE 102 may restart the timer according to a default value (e.g., if the downlink message does not have 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., the new timer value).

[0112] In other implementations, CN 110 determines that UE 102 is approaching the outer boundary of the NTN coverage and sends a downlink message to change the timer and / or force the timer to stop and release the NAS signaling connection, as described herein with respect to Figure 6B and Figure 10 shown.

[0113] At blocks 916 and 918, UE 102 detects expiration of the timer and releases the signaling connection in response to the timer expiration, as described above with respect to Figure 8 It should be understood that in some implementations, UE 102 may instead receive an RRC release message and subsequently stop the timer and release the connection, similar to Figure 8 Thus, depending on the implementation, the UE 102 may perform actions similar to blocks 820 and 822 instead of blocks 916 and 918.

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

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

[0116] At block 1004, CN 110 transmits a downlink message (e.g., Figure 6A and Figure 6B Event 608). The downlink message includes the Figure 6A and Figure 6B The signaling connection management information in question may thus include information such as a timer value, an amount by which a default timer is modified, an indication to use a default timer, a binary flag indicating whether to use one of two timers, and the like.

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

[0118] After setting the timer, UE 102 and CN 110 will eventually plan to release the connection of UE 102 in response to the timer expiring. Depending on the implementation, CN 110 may force the connection release (e.g., as described above). Figure 6B ) or the connection may be allowed to release naturally (e.g., as described above Figure 6A ). Therefore, at block 1007, CN 110 determines whether to send a release command to UE 102. If CN 110 determines to send a release command, the flow continues to block 1008, where CN 108 transmits a command (e.g., Figure 6B Then, at block 1010, CN 110 stops the timer (e.g., Figure 6B If CN 110 determines not to send a release command, flow continues to block 1012 where CN 110 detects expiration of a timer (e.g., Figure 6AAfter the timer stops or expires, flow continues from block 1010 or block 1012 to block 1014, where CN 110 releases the signaling connection (e.g., Figure 6A Event 625).

[0119] Next reference Figure 11 Another CN method 1100 may 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, CN 110 establishes a signaling connection with UE 102 via RAN 105. At block 1104, CN 110 sends a downlink message including signaling connection management information to UE 102 via RAN 105. Blocks 1102 and 1104 may be similar to those described above with respect to Figure 10 Therefore, the implementations applied 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 based on the signaling connection management information to maintain the signaling connection, as described above with respect to Figure 10 As described in event 1006.

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

[0122] At block 1108, CN 110 determines to transmit a downlink message (e.g., Figure 6A and Figure 6B 614 / 680), and at block 1110, CN 110 then stops the timer in response to the determination (e.g., Figure 6A and 6BEvents 617 / 680 of FIG. 4 are described in detail below. CN 110 then generates a downlink message to be transmitted. In some implementations, the downlink message includes signaling connection management information to cause a timer to be restarted after the downlink message is transmitted to 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 indicating a modification to a default timer, a timer value used as a flag and indicating a timer, etc.). Subsequently, at block 1112, CN 110 transmits a downlink message (e.g., Figure 6A and Figure 6B If CN 110 includes signaling connection management information in the downlink message, CN 110 may restart the timer (e.g., as described at block 1106).

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

[0124] Blocks 1107, 1108, 1110, 1112, 1114, and / or 1116 may be collectively referred to herein as a data / signaling communication process 1180, similar to the process described above with respect to Figure 6A and Figure 6B The described data / signaling communication process 680. Therefore, the implementation of the events comprising the data / signaling communication process 680 applies similarly to the blocks comprising the data / signaling communication process 1180.

[0125] Next reference Figure 12 , UE method 1200 can be implemented in a suitable UE and includes determining whether to attempt to access the NTN based on whether the UE is in coverage of an NTN node after a backoff timer expires. For clarity, method 1200 is discussed with reference to base station 104, CN 110, UE 102, satellite 304, and satellite 306.

[0126] At block 1202, UE 102 receives a downlink message from CN 110 via an NTN node (e.g., satellite 304 as part of RAN 105), the downlink message including the information described above with respect to Figure 7 The backoff timer value described (e.g. Figure 7 At block 1204, UE 102 starts a backoff timer (e.g., Figure 7 Event 714 of FIG. 12 shows an example of a method for UE 102 to start a backoff timer. Specifically, UE 102 starts a backoff timer such that, at block 1206, UE 102 avoids accessing the NTN while the backoff timer is running. Depending on the implementation, UE 102 may use the backoff timer value to start the backoff timer according to various methods. For example, in some implementations, UE 102 directly uses the backoff timer value to start the backoff timer (e.g., such that the length of the backoff timer is the backoff timer value). In further implementations, UE 102 starts the backoff timer by modifying a default timer based on the backoff timer value. In still further implementations, the backoff timer value is a binary flag, and UE 102 selects one of a plurality of timers based on the backoff timer value.

[0127] At block 1208, the UE 102 determines that the UE 102 is outside of a coverage area associated with an NTN node while the backoff timer is running (e.g., Figure 7 Event 732 of FIG. 732). In some implementations, the UE 102 determines that the UE 102 is outside the coverage area based on ephemeris information (e.g., detailing the expected position and / or location information of the satellites 304). In further implementations, the UE 102 determines that the UE 102 is outside the coverage area based on the UE 102 location information. The UE 102 may be configured as described elsewhere herein (particularly with respect to FIG. 732 above). Figure 7 Then, in some implementations, at block 1210, 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 active mode, paging updates (e.g., small data or early data transmissions) to CN 110, camping on a cell, etc.

[0128] At block 1212, UE 102 detects that a backoff timer has expired (e.g., Figure 7 Once the backoff timer expires, the UE 102 evaluates whether to attempt to access the NTN again. Specifically, at block 1214, the UE 102 determines whether the UE 102 is in a coverage area associated with a node of the NTN (such as satellite 306) (e.g., Figure 7734). In various implementations, the UE 102 makes a determination based on similar factors as determining that the UE 102 is out of coverage, such as those described above at block 1208. If the UE 102 is in coverage, the flow continues to block 1216. Otherwise, the flow instead continues to block 1220, where the UE 102 refrains from performing idle mode tasks, and continues to block 1222, where the UE 102 refrains from accessing the NTN.

[0129] At block 1216, the UE 102 begins executing the idle mode task. In some implementations, the idle mode task is the same task that was previously stopped at block 1210. In further implementations, the idle mode task is a different task with a higher 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., Figure 7 Depending on the implementation, UE 102 may access the NTN as part of the idle mode task that begins at block 1216.

[0130] Next reference Figure 13 , CN method 1300 can be implemented in a suitable CN and includes estimating a time when a UE leaves the coverage area of ​​an NTN and determining a backoff timer value based on the estimation. For clarity, method 1300 is discussed with reference to base station 104, CN 110, UE 102, and satellite 304.

[0131] At block 1302, the CN 110 receives an uplink message (e.g., Figure 7 Event 706). 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, CN 110 estimates when UE 102 will leave the coverage area associated with the NTN node (e.g., Figure 7 Event 708 of FIG. 708 ). In some implementations, CN 110 generates an estimate of when UE 102 is out of coverage based on ephemeris information (e.g., detailing the expected positioning and / or position information of satellites 304). In further implementations, CN 110 generates the estimate based on UE 102 position information. CN 110 may generate the estimate as further described herein (particularly with respect to FIG. 708 , above). Figure 7 At block 1306, CN 110 determines a backoff timer value (e.g., Figure 7For example, in some implementations, CN 110 determines the backoff timer value to match the estimate. In further implementations, 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 the 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 NTN-related parameters, as described below with respect to Figure 14 Depending on the implementation, the NTN related parameters include any one 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 a downlink message (e.g., Figure 7 Event 712).

[0134] Next reference Figure 14 , 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 is about to leave the coverage area of ​​the NTN. For clarity, method 1400 is discussed with reference to base station 104, CN 110, UE 102, and satellite 304.

[0135] At block 1402, the CN 110 receives a first message (e.g., Figures 6A to 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, CN 110 determines to transmit a downlink message to UE 102 in response to the first message.

[0136] At block 1406, CN 110 estimates the remaining time interval during which UE 102 is in the coverage area associated with the NTN node, similar to the above. Figure 13 1304. Therefore, the implementation described with respect to block 1304 applies similarly to block 1406. At block 1408, CN 110 determines whether the estimated remaining time is greater than a predetermined threshold. Depending on the implementation, the predetermined threshold may be a predetermined value generally used for NTN nodes at CN 110, a predetermined value based on ephemeris information from a specific NTN node, a predetermined value based on information from a specific UE (e.g., UE 102), etc. If the estimated remaining time is greater than the threshold, the process continues to block 1412. Otherwise, the process continues to block 1410.

[0137] At block 1410, the CN 110 may include NTN-related parameters for the UE 102 in a 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 power saving mode, on-duration, off-duration, eDRX parameters, small data transmission parameters, connectivity parameters, etc.), updated NTN coverage information (e.g., movement of satellites 304 or 306 associated with the NTN, updated coverage maps, etc.), and parameters related to UE mobility in the NTN (e.g., updated tracking area identifier (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 a downlink message (e.g., Figures 6A to 7 Event 608 / 618 / 680 or 712).

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

[0139] At block 1502, UE 102 transmits an uplink message (e.g., a base station 104 associated with an NTN (e.g., such as satellite 304 acting as base station 104 of RAN 105) to CN 110. Figure 7 At block 1504, UE 102 receives, via base station 104 and in response to transmitting an uplink message to 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., Figure 7 and Figure 12 At block 1506, UE 102 starts a timer having a duration based on the indication, and at block 1508, UE 102 uses the timer to control when UE 102 attempts to detect a cell associated with a node of the NTN (e.g., Figure 7 and Figure 12 Events 714 and 1204).

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

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

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

[0143] In general, the description of one of the figures above may apply to another of the figures above. If there is no conflict, the examples, implementations, and methods described above may be combined. The above-mentioned events or boxes may be optional or omitted. For example, the events or boxes with dotted lines in the figures may be optional. In some implementations, "message" is used and "information element (IE)" can be used to replace "message", and vice versa. In some implementations, "IE" is used and "field" can be used to replace "IE", and vice versa. In some implementations, "configuration" or "configuration parameter" can be used to replace "configuration", and vice versa.

[0144] The user device (e.g., UE 102) in which the technology of the present disclosure may be implemented may be any suitable device capable of wireless communication, such as a smartphone, tablet computer, laptop computer, mobile game console, point of sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or another personal media device, wearable device such as a smart watch, wireless hotspot, femtocell or broadband router. Further, in some cases, the user device may be embedded in an electronic system such as a head unit or an advanced driver assistance system (ADAS) of a vehicle. Further, the user device may operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may 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 multiple components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and can be configured or arranged in a particular manner. A hardware module can include dedicated circuitry or logic that is permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.). A hardware module can also include programmable logic or circuitry that is temporarily configured by software to perform certain operations (e.g., as contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module with dedicated and permanently configured circuitry or with temporarily configured circuitry (e.g., configured by software) can be driven by cost and time considerations.

[0146] When implemented in software, the techniques may be provided as part of the operating system, as a library used by multiple applications, as a specific software application, etc. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.

Claims

1. A method (800) performed by a user equipment (UE) (102) communicating with a core network (CN) node (110) via a non-terrestrial network (NTN) (105), the method comprising: receiving (806) a first downlink message including signaling management information from the CN node via the NTN; starting (812, 814) a timer having a duration determined based on the signaling management information; as well as The timer is used (818, 820) to control when the UE transitions (822) to idle mode by releasing a signaling connection between the UE and the CN node.

2. The method according to claim 1, wherein The signaling management information includes timer parameters indicating the following: (i) adjusting the default timer value to produce the amount of said duration, or (ii) the value of the duration.

3. The method of claim 1, further comprising: receiving a second downlink message after said starting of said timer; as well as The timer is stopped in response to the reception of the second downlink signal.

4. The method of claim 3, further comprising: The timer is restarted using a default timer value or an updated timer value determined based on second signaling management information included in the second downlink message.

5. The method according to any one of claims 3 or 4, wherein The second downlink message is a downlink non-access stratum (NAS) message, the downlink NAS message including NTN communication parameters for the UE, the NTN communication parameters including at least one of the following: (i) UE power parameters; (ii) NTN coverage parameters; or (iii) UE mobility parameters.

6. The method according to any one of claims 1 to 5, wherein The use includes: When the timer expires, the signaling connection is released.

7. The method according to any one of claims 1 to 6, further comprising: receiving a command to release radio resources; In response to receiving the command to release the radio resources, the timer is stopped and the signaling connection between the UE and the CN is released.

8. The method according to any one of claims 1 to 7, wherein The first downlink message is a downlink (DL) non-access stratum (NAS) message including a tracking area update message or an action reject.

9. A user equipment (UE) (102) comprising a transceiver (134, 136) and a processor (132), the processor being configured to perform the method according to any one of claims 1 to 8.

10. A method (1100) performed by a core network (CN) node (110) communicating with a user equipment (UE) (102) via a non-terrestrial network (NTN) (105), the method comprising: transmitting (1104) a first downlink message including first signaling management information to the UE via a base station associated with the NTN; starting (1106) a timer having a duration indicated in the first signaling management information, the duration taking into account an upcoming out-of-NTN coverage period for the UE; as well as The timer is used (1012) to control when to release the signaling connection between the UE and the CN node.

11. The method according to claim 10, wherein: The first signaling management information includes timer parameters indicating the following items: (i) adjusting the default timer value to produce the amount of said duration, or (ii) the value of the duration.

12. The method according to any one of claims 10 or 11, further comprising: performing a signaling communication process with the UE; In response to the executing, stopping the timer; Transmitting a second downlink message including second signaling management information to the UE; as well as The timer is restarted according to the updated value of the timer parameter included in the second signaling management information.

13. The method of claim 12, wherein: The second downlink message is a downlink non-access stratum (NAS) message, the downlink NAS message including NTN node communication parameters for the UE, the NTN node communication parameters specifying at least one of the following: (i) UE power parameters; (ii) NTN coverage parameters; or (iii) UE mobility parameters.

14. The method of claim 13, wherein: In response to determining that the remaining time of the timer is less than a predetermined time threshold, the second downlink message includes the NTN node communication parameter.

15. The method according to any one of claims 10 to 14, wherein The use includes: When the timer expires, the signaling connection between the UE and the CN is released.

16. The method of any one of claims 10 to 15, further comprising: After said starting of said timer, receiving an uplink message from said UE via said NTN node; stopping the timer in response to receiving the uplink message; as well as Restart the timer.

17. A network node (110) comprising a transceiver (144, 146) and a processor (142), the processor being configured to perform the method according to any one of claims 10 to 16.

Images