EP4674068A1

EP4674068A1 - Managing user equipment access to a non-terrestrial network

Info

Publication number: EP4674068A1
Application number: EP24719766.8A
Authority: EP
Inventors: Chih-Hsiang Wu; Sang Min Park
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-03-31
Filing date: 2024-03-19
Publication date: 2026-01-07
Also published as: CN121039975A; WO2024205993A1

Abstract

Methods and devices (102, 110) implement techniques for managing access (602) to non-terrestrial network, NTN, cells distinctly from access to all cells of a radio access network, RAN. The RAN specifies (606) an NTN-cell-specific cause when rejecting a user equipment, UE, request to access NTN cells. The NTN-cell-specific cause refers to the NTN cells only, not to all the cells (i.e., not also to the TN cells). The NTN‑cell-specific cause may be, for example, lack of adequate NTN subscription or NTN cell temporary unavailability. In response to receiving the NTN-cell-specific cause, the UE may suspend (608) its attempts to access the NTN cells.

Description

MANAGING USER EQUIPMENT ACCESS TO A NON-TERRESTRIAL NETWORK

FIELD OF THE DISCLOSURE

[0001] This document generally describes methods, devices operating in radio access communication systems, such as 3GPP communication systems.

BACKGROUND

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

[0003] Contemporary 5G technology relies primarily on terrestrial networks. However, the 3rd Generation Partnership Project (3GPP) organization proposed extending 5G communications to non-terrestrial networks (NTNs) with 5G new radio (NR) technologies, or with the Long-Term-Evolution (LTE) technologies tailored for the Narrowband Internet-of-Thing (NB-loT) or the enhanced Machine Type Communication (eMTC) scenarios. In an NTN, an RF transceiver is mounted on an aerial vehicle such as a satellite, an uncrewed aircraft system (UAS) also referred to as drone, balloon, plane, etc. For simplicity, the discussion below refers to all such aerial vehicles as satellites. In addition to satellites, an NTN can include the sat-gateways that connect the NTN to a public data network, feeder links between satellite gateways (called “sat-gateways” or NTN-gateways”) and satellites, service links between satellites, and inter-satellite links (ISL) when satellites form constellations.

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

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

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

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

[0008] A contemporary 5G wireless network does not manage differently a UE’s access to terrestrial network, TN, cells versus non-terrestrial network, NTN cells. A network has no defined technique to restrict the UE to access TN cells only, for example. Moreover, if a UE’s registration is denied because NTN cells are congested, there is no clear technique for the UE to interpret the rejection as being limited to the NTN cells so that the UE may continue seeking access via TN cells.

SUMMARY

[0009] A radio access network (RAN) managing distinctly a UE’s access to NTN cells overcomes the problems described in the background section. The RAN specifies an NTN-cell-specific cause when rejecting a UE request to access NTN cells. The NTN- cell-specific cause refers to the NTN cells only, not to all the RAN cells (i.e., does not extend to the TN cells). The NTN-cell-specific cause may be, for example, a lack of adequate NTN subscription or an NTN cell unavailability. A network entity, NE, receiving a UE access request to NTN cells may initiate communication with another NE to retrieve the UE’s subscription information. In response to receiving an NTN-cell- specific cause, the UE may suspend its NTN attempts to access the NTN cells thereby saving power and communication resources. When the NTN-cell-specific cause is lack of adequate NTN subscription, the UE may disable its NTN capability. When the NTN- cell-specific cause is NTN cell unavailability, the UE pauses its search for access to NTN cells for a waiting time interval, which may be predefined or indicated by the NE.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 illustrates a wireless communication system that implements techniques for distinctly managing UE access to NTN cells.

[0011] Figure 2 is a block diagram of an example protocol stack for a UE communicating with a network entity, NE.

[0012] Figure 3 is a block diagram of an example NTN node with transparent payload implementation.

[0013] Figure 4 illustrates an exemplary user plane protocol stack.

[0014] Figure 5 illustrates an exemplary control plane protocol stack. [0015] Figure 6 is a first scenario in which the NE rejects the UE’s request via a satellite, according to an embodiment.

[0016] Figure 7 is a second scenario similar to the first scenario but here the UE has access to TN cells pertaining to a different radio access network than the radio access network to which the NTN cells pertain, according to an embodiment.

[0017] Figure 8 is a third scenario in which the NE rejects the UE’s request temporarily according to an embodiment.

[0018] Figure 9 is a fourth scenario similar to Figure 8 but here the UE has access to TN cells pertaining to a different radio access network than the radio access network to which the NTN cells pertain, according to an embodiment.

[0019] Figure 10 is a flowchart of a UE method corresponding to the first scenario, according to an embodiment.

[0020] Figure 11 is a flowchart of a UE method corresponding to the second scenario, according to an embodiment.

[0021] Figure 12 is a flowchart of a UE method corresponding to the third scenario, according to an embodiment.

[0022] Figure 13 is a flowchart of a UE method corresponding to the fourth scenario, according to an embodiment.

[0023] Figure 14 is a logic flowchart illustrating the behavior of a UE able to perform according to the first and second scenario, according to an embodiment.

[0024] Figure 15 is a logic flowchart illustrating the behavior of a UE able to perform according to the first, second, and third scenarios according to an embodiment.

[0025] Figures 16A, 16B, 16C and 16D are logic flowcharts illustrating the behavior of a UE able to respond to both a conventional cause (indicated by a respective value) of rejecting its registration request and an NTN-cell-specific cause, according to various embodiments.

[0026] Figure 17A is a flowchart illustrating an NE obtaining a UE’s subscription data from another node, according to an embodiment. [0027] Figure 17B is a logic flowchart illustrating an NE obtaining a UE’s subscription data from another node and deciding whether to reject UE’s request based on the subscription data, according to an embodiment.

[0028] Figure 18A is a flowchart illustrating an NE temporarily rejecting a UE’s request, according to an embodiment.

[0029] Figure 18B is a logic flowchart illustrating NE’s action depending on whether NTN services are temporarily unavailable for a UE, according to an embodiment.

[0030] Figure 19 is a flowchart of a method performed by a UE, according to an embodiment.

[0031] Figure 20 is a flowchart of a method performed by an NE, according to an embodiment.

DETAILED DESCRIPTION OF THE DRAWINGS

[0032] As discussed in more detail below, a user equipment (UE) and/or a network node (NE) of a radio access network (RAN) can use the techniques described hereinafter for managing access to NTN cells distinctly.

[0033] Figure 1 schematically illustrates an example wireless communication system 100 with a UE 102, an NTN base station 104, a TN base station 106, and a core network (CN) 110. The base stations 104 and 106 can operate in a RAN 105 connected to the CN 110 and satellite base station components will be described in more detail with reference to Figure 3. The CN 110 may be implemented as an evolved packet core (EPC) 111 , a fifth generation (5G) core (5GC) 160, a sixth generation (6G) core, or a non-3GPP network core.

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

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

[0035] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, a Packet Data Network Gateway (PGW) 116 and a Home Subscriber Server (HSS) 118. The SGW 112 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The HSS 118 is a master user database.

[0036] The 5GC 160 includes a User Plane Function (UPF) 162 and an Access and Mobility Management Function (AMF) 164, Session Management Function (SMF) 166 and a Unified Data Management (UDM) or Unified Data Repository (UDR) 168. Generally speaking, the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions. The UDM/UDR 168 can send and store data such as user subscription information.

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

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

[0039] The base station 104 is equipped with a transceiver and processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non- transitory computer-readable memory storing instructions that the one or more general- purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a processor 132 that prepares downlink data that the base station 104 is to transmit in the downlink direction, or processes uplink data received by the base station 104 in the uplink direction. The processing hardware 130 can also include a transmitter 136 configured to transmit the prepared downlink data in the downlink direction. The processing hardware further can include a receiver 134 configured to receive the uplink data arriving from the uplink direction. The processing hardware further can include an RRC controller 138 configured to implement procedures and messaging at the RRC sublayer of the protocol communication stack. The base station 106 can include generally similar components. In particular, components 140, 142, 144,146, and 148 of the base station 106 can be similar to the components 130, 132, 134, 136, and 138 respectively.

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

[0041] Figure 2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with eNB/ng-eNB or a gNB base stations 204 and 206.

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

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

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

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

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

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

[0048] With LEO/MEO satellites, a base station can provide either quasi-Earth-fixed cell coverage or Earth-moving cell coverage. With GEO satellites, the base station can provide Earth fixed cell coverage.

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

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

[0051] This approach helps to avoid unnecessary measurements and reduce the power consumption of a UE. However, this flexibility comes at the cost of the additional signaling required to inform the UE when to perform measurement on a measurement target (e.g., a cell and/or a carrier frequency). Without the additional signaling, the UE would need to assume the worst-case scenario (in the implementation above, the 5 ms periodicity) to determine when to measure the target. As a result, the UE achieves no power saving gain. This additional signaling in 5G NR is known as “SSB based measurement timing configuration (SMTC),” which contains a periodicity setting ranging from 5 ms to 160 ms and a duration setting ranging from 1 ms to 5 ms.

[0052] The network does not need to align the SMTC periodicity setting with the actual SSB burst periodicity. For instance, the SMTC periodicity can be set to a value larger than the SSB burst periodicity to further reduce the power consumption of the UE. In addition to the periodicity and duration settings, the SMTC also indicates a timing offset to inform the UE of the exact subframe where the UE should start monitoring the SSB burst, which occurs repeatedly according to the periodicity setting. A base station can signal the periodicity and the timing offset settings together, in one measurement object, as a single parameter periodicityAndOffset.

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

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

[0055] Next, embodiments of techniques for managing UE access to NTN that can be implemented in a wireless communication system as the one illustrated in Figure 1 are discussed next with reference to Figures 6-20. Similar events and actions in Figures 6- 20 are labeled with the same or similar reference numbers, with differences discussed 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 or action (e.g., for messaging and processing) may apply to events and actions labeled with similar reference numbers in other figures and also to both integrated and distributed base stations.

[0056] Figure 6 illustrates a scenario 600 in which a UE 102 communicates with a CN 110 via a base station 104 including the satellite 304. In this scenario, the UE 102 initially operates in a connected state in coverage of the satellite 304 and transmits 602 an UL NAS message to the CN 110 (e.g., the MME 114 for EPS or AMF 164 for 5GS) via the base station 104 and the satellite 304. For example, in some implementations, the connected state is an ECM-CONNECTED state or EMM-CONNECTED state for an MME 114. In further implementations, the connected state is a 5GCM-CONNECTED state or 5GMM-CONNECTED state in the case of the AMF 164. In still further implementations, the connected state is an RRC_CONNECTED state. When the CN 110 receives the UL NAS message, the CN 110 determines 604 that the UE 102 is not allowed to access an NTN cell (i.e., the UE 102 is not allowed to access the CN 110 and/or RAN 105 via a satellite). In some implementations, the LIE 102 is not allowed to access the NTN cell because the CN 110 determines that the UE 102 does not subscribe to NTN services based on subscription data for the UE 102. In the case that the CN 110 is an EPC 111 , when the MME 114 receives 602 the UL NAS message, if the MME 114 does not have subscription data stored for the UE 102, the MME 114 may transmit a first message to another network node (e.g., HSS 118) to request subscription data for the UE 102. In response, the other network node transmits a second message including subscription data for the UE 102 to the MME 114. The MME 114 determines that the UE 102 is not allowed to access the NTN cell based on the subscription data received. In the case that the CN 110 is a 5GC 160, when the AMF 164 receives 602 the UL NAS message, if the AMF 164 does not have subscription data stored for the UE 102, the AMF 164 may transmit a first message to another network node (e.g., UDM/UDR 168) to request subscription data for the UE 102. In response, the network node transmits a second message including subscription data for the UE 102 to the AMF 164. The AMF 164 determines that the UE 102 is not allowed to access the NTN cell based on the subscription data received.

[0057] In response to determining that the UE 102 is not allowed to access the NTN cell, the CN 110 generates a DL NAS message including an NTN-specific cause and transmits 606 the DL NAS message to the UE 102 via the base station 104 and the satellite 304. The NTN-specific cause indicates that NTN services are not allowed for the UE 102 (i.e. , the UE 102 is not allowed to access the NTN cell indicated in the request). Note that techniques of providing a cause value for rejecting access to all network cells (i.e., non-NTN-specific) are described in 3GPP 24.501.

[0058] In some implementations, the UL NAS message and the DL NAS message are a Registration Request message and a Registration Reject message, respectively. In other implementations, the UL NAS message and the DL NAS message are an Attach Request message and an Attach Reject message, respectively. In yet other implementations, the UL NAS message and the DL NAS message are a Tracking Area Update Request message and a Tracking Area Update Reject message, respectively. [0059] After receiving 606 the DL NAS message, the LIE 102 disables 608 NTN capability in response to receiving the NTN-specific cause. The term “NTN-specific cause” means that a cause specified in the DL NAS message has a value corresponding to an NTN-only related reason for rejection. Values of the cause included in the DL may also indicate a reason related to both NTN and TN. For simplicity of the description, referring to “value” is omitted. The UE 102 performs a cell search to find a terrestrial network (TN) cell after receiving (e.g., in response to) the NTN-specific rejection cause or disabling the NTN capability. During the cell search, the UE 102 may find and select 610 a TN cell belonging to the base station 106. After selecting the TN cell, the UE 102 transmits 612 a UL NAS message to the CN 110 via the base station 106 and the TN cell. In response, the CN 110 transmits 614 a DL NAS message to the UE 102 via the base station 106 and the TN cell to grant the UE 102 access to a TN connecting to the CN 110. In response, the UE 102 optionally transmits 615 a UL NAS message to the CN 110 via the TN cell and base station 106. In some implementations, if the TN cell is a 5G NR cell, the UL NAS message 612, the DL NAS message 614, and optional UL NAS message 615 are a Registration Request message, a Registration Accept message, and a Registration Complete message, respectively. In other implementations, if the TN cell is an LTE cell, the UL NAS message 612, the DL NAS message 614, and the optional UL NAS message 615 are an Attach Request message, an Attach Accept message, and an Attach Complete message, respectively. In yet other implementations, if the TN cell is an LTE cell, the UL NAS message 612, the DL NAS message 614, and the optional UL NAS message 615 are a Tracking Area Update Request message, a Tracking Area Update Accept message, and a Tracking Area Update Complete message, respectively.

[0060] Later in time, the UE 102 may enable 616 the NTN capability. In some implementations, the UE 102 enables the NTN capability due to a power cycle (i.e. , the UE 102 is switched off and on). In other implementations, the UE 102 enables the NTN capability after the UE 102 turns airplane mode on and off. In yet other implementations, the UE 102 enables the NTN capability due to changing a Universal Subscriber Identity Module (USIM). In yet another implementation, the UE 102 enables the NTN capability due to removal and/or insertion of a USIM.

[0061] After enabling the NTN capability, the UE 102 may select 618 an NTN cell of the base station 104 (or a different base station). The base station 104 may operate the NTN cell via the satellite 306. In some other scenarios, the base station 104 may still operate the NTN cell via the satellite 304. The UE 102 may then transmit 620 a UL NAS message to the CN 110 via the NTN cell and the base station 104. In response, the CN 110 may transmit 622 a DL NAS message to the UE 102 via the base station 104 and the NTN cell. In some implementations, the UL NAS message 620 is a Registration Request message. Depending on implementation, the DL NAS message can be similar to the DL NAS message 606 or the DL NAS message 614. For example, if the CN 110 still determines that the UE 102 is not allowed to access an NTN (i.e. , the UE 102 is not allowed to access the CN 110 and/or RAN 105 via a satellite), the CN 110 includes the NTN-specific cause in the DL NAS message 622 which may be similar to message 606. After receiving the NTN-specific cause in the DL NAS message 622, the UE 102 may disable the NTN capability, select a TN cell, transmit a UL NAS message, receive a DL NAS message, and/or transmit an optional UL NAS message, similar to the events 608, 610. 612, 614, and/or 615, respectively. In another example, if the CN 110 determines that the UE 102 is allowed to access an NTN cell, the CN 110 grants the UE 102 a configuration to access the NTN cell in or via the DL NAS message 622. In this case, after receiving 622 the DL NAS message, the UE 102 may transmit a UL NAS message to the CN 110 via the NTN cell and base station 104, similar to the event 615.

[0062] Referring next to Figure 7, another scenario 700 is shown in which the base station 104 of the RAN 105 includes a satellite 304, similar to the example scenario 600. Events 702, 706, 710, 712, 714, 715, 718, 720, and 722 are similar to events 602, 606, 610, 612, 614, 615, 618, 620, and 622, respectively. The differences between the scenario 600 and scenario 700 are described below.

[0063] When the 5GC 160 (e.g., AMF 164 for 5GS) receives 702 the UL NAS message, the 5GC 160 determines 704 that the UE 102 is not allowed to access both 5G TN and 5G NTN, based on subscription data for the UE 102. In response to determining that the UE 102 is not allowed to access an NTN or TN 5G cell, the CN 110 generates a DL NAS message including a cause and transmits 706 the DL NAS message to the UE 102 via the base station 104 and the satellite 304. The cause (i.e. , its value) indicates 5G TN and 5G NTN services not allowed for the UE 102 (i.e., the UE 102 is not allowed to access 5G TN and 5G NTN).

[0064] After receiving 706 the DL NAS message, the UE 102 disables 708 5G TN capability and 5G NTN capability in response to receiving the cause. The UE 102 performs a cell search to find an LTE (or other non-5G) cell after receiving (e.g., in response to) the cause or disabling the 5G TN capability and 5G NTN capability. During the cell search, the UE 102 may find and select 710 an LTE cell belonging to the base station 106. In one implementation, if the UE 102 supports LTE NTN access, the UE 102 may (still) enable the LTE NTN capability, after receiving (e.g., in response to) the cause. In this case, the LTE cell is shown as a TN cell but could be an LTE NTN cell. In another implementation, the UE 102 may disable both 5G NTN and LTE NTN capabilities, after receiving (e.g., in response to) the cause. In the cell search, the UE 102 does not search a LTE NTN cell. After selecting the LTE cell, the UE 102 transmits 712 a UL NAS message to the EPC 111 (e.g., the MME 114) via the base station 106 and the LTE cell. In response, the EPC 111 transmits 714 a DL NAS message to the UE 102 via the base station 106 and the LTE cell to grant the UE 102 to access an LTE network connecting to the EPC 111. In response, the UE 102 may optionally transmit 715 a UL NAS message to the CN 110 via the LTE cell and base station 106.

[0065] Later in time, the UE 102 may enable 716 the 5G TN capability and/or the 5G NTN capability. In some implementations and/or scenarios, after enabling the 5G NTN capability, the UE 102 selects 718 a 5G NTN cell operated by the base station 104. The base station 104 may operate the 5G NTN cell via the satellite 306. In some other scenarios, the base station 104 may still operate the 5G NTN cell via the satellite 304. The UE 102 may then transmit 720 a UL NAS message to the 5GC 160 via the 5G NTN cell and the base station 104. In response, the 5GC 160 may transmit 722 a DL NAS message to the UE 102 via the base station 104 and the 5G NTN cell. In some implementations, the UL NAS message 720 is a Registration Request message. In some implementations, the DL NAS message can be similar to the DL NAS message 606 or 706. For example, if the 5GC 160 determines that the UE 102 is still not allowed to access 5G TN and 5G NTN cells, the 5GC 160 includes a cause value indicating a TN and non-NTN rejection in the DL NAS message 722. In this case, the DL NAS message is a Registration Reject message. After receiving the cause in the DL NAS message 722, the UE 102 may disable the 5G TN capability and the 5G NTN capability, select an LTE cell, transmit a UL NAS message, receive a DL NAS message, and/or transmit a UL NAS message, similar to the events 708, 710, 712, 714, and/or 715, respectively. In other implementations, if the 5GC 160 determines that the UE 102 is allowed to access 5G TN and 5G NTN cells, the 5GC 160 grants the UE 102 access to the 5G TN and 5G NTN cell in or via the DL NAS message 722. For example, the DL NAS message 722 is a Registration Accept message. In response to the Registration Accept message, the UE 102 may transmit a Registration Complete message to the 5GC 160 via the 5G NTN cell and the base station 104.

[0066] In other implementations and/or scenarios, if the 5GC 160 determines that the UE 102 is not allowed to access only NTN cells, the 5GC includes an NTN-specific cause (e.g., the cause value from message 606) in the DL NAS message 722. After enabling the 5G TN capability, the UE 102 may select a 5G TN cell operated by a base station (see Figure 6 elements 612, 614, 615). The UE 102 may then transmit a UL NAS message to the 5GC 160 via the 5G TN cell and the base station. In response, the 5GC 160 may transmit a DL NAS message to the UE 102 via the base station and the 5G TN cell. In some implementations, the UL NAS message is a Registration Request message. In response to the Registration Accept message, the UE 102 may transmit a Registration Complete message to the 5GC 160 via the 5G TN cell and the base station 104.

[0067] Figure 8 illustrates an example scenario 800 similar to scenario 600, in which the base station 104 of the RAN 105 includes a satellite 304. Events 802, 806, 810, 812, 814, 815, 818, 820, and 822 are similar to events 602, 606, 610, 612, 614, 615, 618, 620, and 622, respectively. The differences between scenario 600 and scenario 800 are described below.

[0068] When the CN 110 (e.g., the MME 114 for EPS or AMF 164 for 5GS) receives 802 the UL NAS message via the base station 104 and the satellite 304, the CN 110 determines 804 that NTN services are temporarily unavailable. In some implementations, the CN 110 determines that NTN services are temporarily unavailable because an NTN cell connecting to the CN 110 is congested. In response to the determination, the CN 110 generates a DL NAS message including an NTN-specific cause and transmits 806 the DL NAS message to the UE 102 via the base station 104 and the satellite 304. The NTN-specific cause (i.e., the value of the cause) indicates that NTN services are temporarily unavailable. In some implementations, the CN 110 determines a value of a time interval for the UE 102 to refrain from accessing NTN cells and sends the value to the UE via the DL NAS message along with the NTN-specific cause.

[0069] After receiving 806 the DL NAS message, the UE 102 starts 807 a timer (e.g., NTN access prohibit timer) in response to receiving the NTN-specific cause and refrains 809 from accessing NTN cells while the timer is running. If a value for 807 the timer is included in 806 the DL NAS message, the UE 102 starts 807 the timer with the received value. In some implementations, the UE 102 starts 807 the timer with pre-defined timer value or with a random value within a pre-defined range. While the timer is running, the UE 102 may perform a cell search to find a TN cell but not to find an NTN cell. During the cell search, the UE 102 may find and select 810 a TN cell belonging to the base station 106. After selecting the TN cell, the UE 102 transmits 812 a UL NAS message to the CN 110 via the base station 106 and the TN cell. In response, the CN 110 transmits 814 a DL NAS message to the UE 102 via the base station 106 and the TN cell to grant the UE 102 to access a TN connecting to the CN 110. In response, the UE 102 may optionally transmit 815 a UL NAS message to the CN 110 via the TN cell and the base station 106. [0070] Later in time, the UE 102 detects that the timer expires. After the timer expires, the UE 102 stops barring access to NTN cells. The UE 102 then may select 818 an NTN cell of the base station 104. The base station 104 may operate the NTN cell via the satellite 306. In some other scenarios, the base station 104 operates the NTN cell via the prior satellite 304. The UE 102 may then transmit 820 a UL NAS message to the CN 110 via the NTN cell and the base station 104. In response, the CN 110 may transmit 822 a DL NAS message to the UE 102 via the base station 104 and the NTN cell. In some implementations, the DL NAS message can be similar to the DL NAS message 806 or the DL NAS message 814. For example, if the CN 110 determines that the NTN is still congested, the CN 110 includes the cause in the DL NAS message 822. After receiving the NTN-specific cause in the DL NAS message, the UE 102 may start the timer, refrain from accessing NTN cells while the timer is running, select a TN cell, transmit a UL NAS message, receive a DL NAS message, and/or transmit a UL NAS message, similar to the events 807, 809, 810, 812, 814, and/or 815, respectively. In another example, if the CN 110 determines that the NTN is no longer congested, the CN 110 grants the UE 102 to access the NTN in or via the DL NAS message 822. In this case, after receiving 822 the DL NAS message, the UE 102 may transmit a UL NAS message to the CN 110 via the NTN cell and base station 104, similar to the UL NAS message in the event 815. Alternatively, the DL NAS message 822 may include other NTN-specific cause values per Figure 6 and Figure 7.

[0071] Figure 9 is an example scenario 900 similar to scenarios 800 and 700 in which the base station 104 of the RAN 105 includes a satellite 304. Events 902, 906, 910, 912, 914, 915, 918, 920, and 922 are similar to events 702, 706, 710, 712, 714, 715, 718, 720, and 722, respectively. Events 902, 906, 910, 912, 914, 915, 918, 920, and 922 are also similar to events 802, 806, 810, 812, 814, 815, 818, 820, and 822, respectively. The differences between scenarios 700, 800 and 900 are described below. [0072] When the 5GC 160 (e.g., AMF 164 for 5GS) receives 902 the UL NAS message via the base station 104 and the satellite 304, the 5GC 160 determines 904 that the 5G TN services and 5G NTN services are temporarily unavailable. In some implementations, the CN 110 determines that both 5G TN and 5G NTN services are temporarily unavailable because 5G TN and 5G NTN cells connecting to the 5GC 160 are congested. In response to the determination, the 5GC 160 generates a DL NAS message including a cause (non-NTN-specific value) and transmits 906 the DL NAS message to the UE 102 via the base station 104 and the satellite 304. The cause indicates that both 5G TN and 5G NTN services are temporarily unavailable. In some implementations, the CN 110 determines a value for a timer for refraining the UE 102 from accessing 5G TN and NTN cells while the timer is running and provide the value to the UE via the DL NAS message along with the cause.

[0073] After receiving 906 the DL NAS message, the UE 102 starts 907 a timer (e.g., 5G TN and 5G NTN access prohibit timer) in response to receiving the cause and refrains 909 from accessing 5G TN cells and 5G NTN cells while the timer is running. If a value for the timer is included in the DL NAS message, the UE 102 starts 907 the timer with the received value. In some implementations, the UE 102 starts 907 the timer with pre-defined timer value or with a random value within a pre-defined range. While the timer is running, the UE 102 may perform a cell search to find an LTE cell. During the cell search, the UE 102 may find and select 910 an LTE cell belonging to the base station 106. In one implementation, if the UE 102 supports LTE NTN access, the UE 102 may search a LTE TN cell or a LTE NTN cell in the cell search. In this case, the LTE cell is shown as a TN cell but could be an LTE NTN cell. In other implementations, the UE 102 refrains from searching for a LTE NTN cell while the timer is running, or the UE 102 does not support LTE NTN access. In such cases, the UE 102 does not search a LTE NTN cell in the cell search. After selecting the LTE cell, the UE 102 transmits 912 a UL NAS message to the EPC 111 via the base station 106 and the LTE cell. In response, the EPC 111 transmits 914 a DL NAS message to the UE 102 via the base station 106 and the LTE cell to grant the UE 102 to access an LTE network connecting to the EPC 111. In response, the UE 102 may optionally transmit 915 a UL NAS message to the EPC 111 via the TN cell and the base station 106. [0074] Later in time, the UE 102 detects that the timer expires. After the timer expires, the UE 102 stops barring access to 5G TN cells and 5G NTN cells. In some implementations and/or scenarios, the UE 102 then may select 918 a 5G NTN cell of the base station 104. The base station 104 may operate the 5G NTN cell via the satellite 306. In some other scenarios, the base station 104 may still operate the 5G NTN cell via the satellite 304. The UE 102 may then transmit 920 a UL NAS message to the 5GC 160 via the 5G NTN cell and the base station 104. In response, the 5GC 160 may transmit 922 a DL NAS message to the UE 102 via the base station 104 and the 5G NTN cell. In some implementations, the DL NAS message can be similar to the DL NAS message 906. For example, if the 5GC 160 still determines that both the 5G TN and 5G NTN cells are congested, the 5GC 160 includes the cause in the DL NAS message 922. After receiving the cause in the DL NAS message 922, the UE 102 may start the timer, refrain from accessing 5G TN cells and 5G NTN cells while the timer is running, select a LTE cell, transmit a UL NAS message, receive a DL NAS message, and/or transmit a UL NAS message, similar to the events 907, 909, 910, 912, 914, and/or 915, respectively. In other implementations, the DL NAS message can be similar to the DL NAS message 806 with a cause value that specifies only the NTN-cell is congested. In some implementations, if the 5GC 160 determines that the 5G TN and 5G NTN are no longer congested, the 5GC 160 grants the UE 102 to access the 5G TN and 5G NTN in or via the DL NAS message 922. For example, the DL NAS message 922 is a Registration Accept message. In response to the Registration Accept message, the UE 102 may optionally transmit (not shown) a Registration Complete message to the 5GC 160 via the 5G NTN cell and the base station 104.

[0075] In other implementations and/or scenarios, after detecting 917 the timer expires, the UE 102 selects a 5G TN cell. The UE 102 may then transmit a UL NAS message to the 5GC 160 via the 5G TN cell and the base station. In response, the 5GC 160 may transmit a DL NAS message to the UE 102 via the base station 104 and the 5G TN cell. In some implementations, the DL NAS message can be similar to the DL NAS message 906. For example, if the 5GC 160 still determines that the 5G TN and 5G NTN are still congested, the 5GC 160 includes the relevant cause value in the DL NAS message. After receiving the cause in the DL NAS message, the UE 102 may start the timer, refrain from accessing 5G TN cells and 5G NTN cells while the timer is running, select a LTE cell, transmit a UL NAS message, receive a DL NAS message, and/or transmit a UL NAS message, similar to the events 907, 909, 910, 912, 914, and/or 915, respectively. In other implementations, the DL NAS message can be similar to the DL NAS message 914. In some implementations, if the 5GC 160 determines that the 5G TN and 5G NTN are no longer congested, the 5GC 160 grants the UE 102 to access the 5G NTN in or via the DL NAS message. For example, the DL NAS message is a Registration Accept message. In response to the Registration Accept message, the UE 102 may optionally transmit (not shown) a Registration Complete message to the 5GC 160 via the 5G TN cell and the base station.

[0076] Next, several example methods that can be implemented in a UE (e.g., the UE 102) or a CN (also called network entity, NE) such as an MME or an AMF are discussed with reference to Figs. 10-18. 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 computer memory.

[0077] Figure 10 is a flowchart of a method 1000 that can be implemented in a suitable UE (e.g., the UE 102) and includes disabling an NTN capability of the UE in response to receiving an NTN-specific cause value.

[0078] The method 1000 begins at block 1002, where the UE transmits an NTN access request (e.g., event 602) and receives, at block 1006, a DL message including an NTN-specific cause (e.g., indicating NTN services are not allowed) from a network via a satellite (e.g., event 606). At block 1008, the UE disables the NTN capability in response to (receiving) the cause (e.g., event 608). At block 1010, the UE selects the TN cell (e.g., event 610), after receiving the DL message or cause or disabling the NTN capability. In some implementations, the UE performs a cell search to search a TN cell, after (e.g., in response to) receiving the DL message or cause or disabling the NTN capability. The UE finds the TN cell in the cell search and selects the TN cell at block 1010. At block 1013, the UE communicates with the network via the TN cell (e.g., events 612, 614, 615). At block 1016, the UE enables the NTN capability (e.g., event 616). At block 1018, the UE selects a NTN cell after enabling the NTN capability (e.g., event 618). In some implementations, the UE performs a cell search to search a NTN cell, after enabling the NTN capability. The UE finds the NTN cell in the cell search and selects the NTN cell. At block 1021 , the UE communicates with the network via the NTN cell (e.g., events 620, 622).

[0079] Figure 11 is a flowchart of another method 1100 that can be implemented in a suitable UE (e.g., the UE 102) and includes disabling a 5G TN capability and a 5G NTN capability of the UE.

[0080] The method 1100 begins at block 1102, where the UE transmits an NTN access request, and then the UE receives, at block 1106, a DL message including a cause from a 5GC network (e.g., event 706). At block 1108, the UE disables 5G TN capability and 5G NTN capability in response to (receiving) the cause (e.g., event 708). At block 1110, the UE selects an LTE cell, after receiving the DL message or cause or disabling the 5G TN capability and 5G NTN capability (e.g., event 710). In some implementations, the UE performs an LTE cell search to search an LTE cell, after receiving (e.g., in response to) the DL message or cause or disabling the 5G TN capability and 5G NTN capability. The UE finds the LTE cell in the LTE cell search and selects the LTE cell at block 1110. At block 1113, the UE communicates with an EPC via the LTE cell (e.g., events 712, 714, 715). At block 1116, the UE enables the 5G TN capability and/or 5G NTN capability (e.g., event 716). At block 1118, the UE selects a 5G NTN cell after enabling the 5G NTN capability (e.g., event 718). In some implementations, the UE performs a 5G cell search to search a 5G NTN cell after enabling the 5G NTN capability. The UE finds the 5G NTN cell in the cell search and selects the 5G NTN cell in block 1118. At block 1121 , the UE communicates with the network via the 5G NTN cell (e.g., events 720, 722). At block 1126, the UE selects a 5G TN cell after enabling the 5G TN capability. In some implementations, the UE performs a 5G cell search to search a 5G TN cell after enabling the 5G TN capability. The UE finds the 5G TN cell in the cell search and selects the 5G TN cell in block 1116. At block 1118, the UE communicates with the 5GC network via the TN cell.

[0081] Figure 12 is a flowchart of a method 1200 that can be implemented in a suitable UE (e.g., the UE 102) and includes managing access to an NTN.

[0082] The method 1200 begins at block 1202, where the UE transmits an NTN access request (e.g., event 802) and then receives, at block 1206, a DL message including a NTN-specific cause from a network via a satellite (e.g., event 806). At block 1207, the UE starts an NTN access prohibit timer in response to (receiving) the NTN- specific cause (e.g., event 807). At block 1209, the UE refrains from accessing NTN cells while the NTN access prohibit timer is running (e.g., event 809). At block 1210, the UE selects a TN cell while the NTN access prohibit timer is running (e.g., event 810). In some implementations, the UE performs a cell search to search a TN cell while the NTN access prohibit timer is running. The UE finds a TN cell in the cell search and selects the TN cell in block 1210. At block 1213, the UE communicates with the network via the TN cell (e.g., events 812, 814, 815). At block 1217, the UE detects the NTN access prohibit timer expires (e.g., event 817). At block 1218, the UE selects an NTN cell after detecting the NTN access prohibit timer expires (e.g., event 818). In some implementations, the UE performs a cell search to search an NTN cell after the detecting the NTN access prohibit timer expires. The UE finds the NTN cell in the cell search and selects the NTN cell in block 1218. At block 1221 , the UE communicates with the network via the NTN cell (e.g., events 720, 722).

[0083] Figure 13 is a flowchart of a method 1300 that can be implemented in a suitable UE (e.g., the UE 102) and includes managing access to an NTN.

[0084] The method 1300 begins at block 1302, where the UE transmits an NTN access request (e.g., event 902), and then receives, at block 1306, a DL message including a cause from a 5GC network (e.g., event 906). At block 1307, the UE starts an access prohibit timer in response to (receiving) the cause (e.g., event 907). At block 1309, the UE refrains from accessing 5G TN cells and 5G NTN cells while the access prohibit timer is running (e.g., event 909). At block 1310, the UE selects an LTE cell while the access prohibit timer is running (e.g., event 910). In some implementations, the UE performs an LTE cell search seeking an LTE cell while the access prohibit timer is running. The UE finds an LTE cell in the LTE cell search and selects the LTE cell in block 1310. At block 1313, the UE communicates with an EPC via the LTE cell (e.g., events 912, 914, 915). At block 1317, the UE detects that the access prohibit timer expires (e.g., event 917). At block 1318, the UE selects a 5G NTN cell after the detecting the access prohibit timer expires (e.g., event 918). In some implementations, the UE performs a 5G cell search to search a 5G NTN cell after the detecting the access prohibit timer expires. The UE finds and selects the 5G NTN cell in block 1318. At block 1321 , the UE communicates with the 5GC network via the 5G NTN cell (e.g., events 920, 922). Alternatively, at block 1324, the UE selects a 5G TN cell after detecting the access prohibit timer expires, communicates, at block 1326, with the 5GC network via the 5G TN cell.

[0085] Figure 14 is a flowchart of a method 1400 that can be implemented in a suitable UE (e.g., the UE 102) and includes managing access to an NTN and a TN. [0086] The method 1400 begins at block 1406, where the UE receives a DL message including a cause from a 5G core network (e.g., events 606, 706). At block 1405, the UE determines whether the cause is set to a first value (an NTN-specific cause) or a second value (impacting both TN and NTN). If the UE determines that the cause is set to a first value at block 1405, the flow proceeds to block 1408. At block 1408, the UE disables 5G NTN capability in response to (receiving) the cause (e.g., event 608). Otherwise, if the UE determines that the cause is set to a second value at block 1405, the flow proceeds to block 1407. At block 1407, the UE disables 5G TN capability and 5G NTN capability in response to (receiving) the cause.

[0087] Figure 15 is a flowchart of a method 1500 can be implemented in a suitable UE (e.g., the UE 102) and includes managing access to an NTN and a TN.

[0088] The method 1500 begins at block 1506, where the UE receives a DL message including a cause from a 5G core network (e.g., events 806, 906). At block 1505, the UE determines whether the cause is set to a first value (an NTN-specific cause) or a second value (impacting both TN and NTN). If the UE determines that the cause is set to a first value at block 1505, the flow proceeds to block 1507A. At block 1507A, the UE starts an NTN access prohibit timer in response to (receiving) the cause (e.g., event 807) and then, at block 1509A, the UE refrains from accessing NTN cells while the NTN access prohibit timer is running (e.g., event 809). Otherwise, if the UE determines that the cause is set to a second value at block 1505, the flow proceeds to block 1507B. At block 1507B, the UE starts an access prohibit timer in response to (receiving) the cause (e.g., event 907) and then, at block 1509B, the UE refrains from accessing 5G TN cells and 5G NTN cells while the access prohibit timer is running (e.g., event 909).

[0089] Figures 16 are flowcharts of methods 1600A-D that can be implemented in a suitable UE (e.g., the UE 102) and include managing access to a NTN and/or a TN. [0090] The method 1600A begins at block 1606A, where the UE receives a DL message including a cause from a 5GC network (e.g., events 606, 706). At block 1605A, the UE determines whether the cause is set to a NTN-specific value. If the UE determines that the cause is set to an NTN-specific value at block 1605A, the flow proceeds to block 1630, that is, the UE proceeds with step (1002-1018) or (1102-1118). Otherwise, if the UE determines that the cause is not set to an NTN-specific value at block 1605A, the flow proceeds to block 1608A. At block 1608A, the UE performs actions based on the cause value in accordance with 3GPP TS 24.501 .

[0091] The method 1600B in Figure 16B is similar to the method 1600A, except that 1606B and 1608B are different from 1606A and 1608A. At block 1606B, the UE receives a DL message including a cause from an EPC (e.g., event 606) not from a 5GC network as in 1606A. At block 1608B, the UE performs actions based on the cause value in accordance with 3GPP TS 24.301 (not in accordance with 3GPP TS 24.501 as in case of 1608A).

[0092] The method 1600C in Figure 16C is similar to the method 1600A, except that block 1605C is different from block 1605A. At block 1605C, the UE determines whether the DL message is received via an NTN. If the UE determines that the DL message is received via an NTN at block 1605C, the flow proceeds to block 1630. Otherwise, if the UE determines that the DL message is received via a TN at block 1605C, the flow proceeds to block 1608A.

[0093] Figure 16D is a flow diagram of a method 1600D similar to the methods 1600B and 1600C. If the UE determines that the DL message is received via an NTN at block 1605D, the flow proceeds to block 1630.

[0094] Figure 17A illustrates a method 1700A, which can be implemented by a first network node (e.g., the CN 110, AMF 164 or MME 114), for managing access to an NTN for a UE (e.g., the UE 102).

[0095] The method 1700A begins at block 1702, where the first network node receives a UL message from a UE (e.g., events 602, 702). At block 1740, the first network node transmits a first message to a second network node (e.g., UDM/UDR 168) to get subscription data for the UE. At block 1742, the first network node receives a second message from the second network node to obtain subscription data for the UE. At block 1744, the first network node determines that the UE is not allowed to access an NTN cell based on the subscription data. At block 1706, the first network node transmits a first DL message indicating that NTN services are not allowed to the UE (e.g., events 606, 706).

[0096] Figure 17B is a flow diagram of an example method 1700B similar to the method 1700A, except that method 1700B includes blocks 1704 and 1746 instead of block 1744. At block 1704, the first network node determines whether the UE is allowed to access NTN based on the subscription data. If the first network node determines that the UE is not allowed to access NTN based on the subscription data at block 1704, the flow proceeds to block 1706. Otherwise, if the first network node determines that the UE is allowed to access an NTN based on the subscription data at block 1704, the flow proceeds to block 1746. At block 1746, the first network node transmits a second DL message the UE. In some implementations, the second DL message grants the UE access to an NTN. For example, the UL message and second DL message are a Registration Request message and a Registration Accept message, respectively. In another example, the UL message and second DL message are an Attach Request message and an Attach Accept message, respectively. In yet another example, the UL message and second DL message are a Tracking Area Update Request message and a Tracking Area Update Accept message, respectively.

[0097] Figure 18A illustrates a method 1800A, which can be implemented by a first network node (e.g., the CN 110, AMF 164 or MME 114), for managing access to a NTN for a UE (e.g., the UE 102).

[0098] The method 1800A begins at block 1802, where the network node receives a UL message from a UE (e.g., event 802). At block 1806, the network node transmits a first DL message indicating NTN services are temporarily not available to the UE (e.g., event 806).

[0099] Figure 18B is a flow diagram of an example method 1800B similar to the method 1800A, except that method 1800B includes blocks 1804 and 1846. At block 1804, the network node determines whether NTN services are available. If the network node determines that NTN services are not available at block 1804, the flow proceeds to block 1806. Otherwise, if the network node determines that NTN services are available at block 1804, the flow proceeds to block 1846. At block 1846, the network node transmits a second DL message the UE. In some implementations, the second DL message grants the UE to access an NTN. For example, the UL message and second DL message are a Registration Request message and a Registration Accept message, respectively. In another example, the UL message and second DL message are an Attach Request message and an Attach Accept message, respectively. In yet another example, the UL message and second DL message are a Tracking Area Update Request message and a Tracking Area Update Accept message, respectively.

[0100] Figure 19 is a flowchart of a method 1900 for a UE according to an embodiment. Method 1900 includes transmitting 1902 a request to access an NTN cell of a first radio access network, RAN, and receiving 1906 a rejection of the request, the rejection indicating an NTN-specific cause for the rejection. Method 1900 may further include suspending attempts to communicate with the NTN cell based on the NTN- specific cause. Further, the suspending may include (1 ) disabling an NTN capability of the UE or (2) starting a timer when the NTN-specific cause indicates that the request is rejected temporarily, renewing the request after the timer expires. The value of the timer may be received via the rejection, predefined, or randomly selected from a predefined range. The NTN cell indicated in the request may pertain to a first RAN, the rejecting also including a TN rejection, and the suspending including suspending attempts to communicate with TN cells of the first RAN; the UE may then transmit a request to connect to a TN of a second RAN. The second RAN may have only TN cells (e.g., an LTE).

[0101] Figure 20 is a flowchart of a method 2000 performed by an NE (e.g., 110), according to an embodiment. Method 2000 includes receiving 2002 from a UE (e.g., 102), a request to access an NTN cell, and transmitting a response rejecting the request, the response including an NTN-specific cause for the rejection. The NTN- specific cause may indicate the UE lacking NTN-access entitlement and is based on subscription information of the UE. Method 200 may further include obtaining the subscription information of the UE from another NE. The NTN-specific cause indicates the first request is rejected temporarily, and, optionally, the response includes a time interval value.

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

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

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

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

Claims

What is claimed is:

1. A method (1000, 1100, 1200, 1300, 1900) performed by a user equipment, UE, (102), the method comprising: transmitting (1902) a first request to access a non-terrestrial network, NTN, cell of a first radio access network; and receiving (1906) a response rejecting the first request, the response indicating a first NTN-specific cause when the UE lacks an NTN-access entitlement, or a second NTN-specific cause when an NTN access is temporarily unavailable.

2. The method of claim 1 further comprising: suspending attempts to communicate with the NTN cell upon receiving the response.

3. The method of claim 2, wherein the suspending comprises: disabling an NTN capability of the UE.

4. The method of claim 2, wherein the suspending comprises: starting a timer when the response indicates the second NTN-specific cause; and renewing the first request after the timer expires.

5. The method of claim 4, wherein the response includes a value for the timer.

6. The method of claim 4, wherein the starting the timer includes applying a predetermined value or selecting a value within a predefined range, for the timer.

7. The method of any of claims 2 to 6, wherein the response also indicates a terrestrial network, TN, rejection, and the suspending includes suspending attempts to communicate with TN cells of the first radio access network, and the method further comprises: transmitting a second request to access a cell of a second radio access network.

8. The method of claim 7, wherein the cell of the second radio access network is a TN cell.

9. The method of claim 7, wherein the second radio access network is a Long Term Evolution, LTE, network.

10. A method (1700A, 1700B, 1800A, 1800B, 2000) performed by a network entity, NE, (110) the method comprising: receiving (1702, 1802, 2002), from a user equipment, UE, (102), a first request to access a non-terrestrial network, NTN, cell; and transmitting (1706, 1806, 2006) a response rejecting the first request, the response including a first NTN-specific cause when the UE lacks an NTN-access entitlement, or a second NTN-specific cause when an NTN access is temporarily unavailable.

11 . The method of claim 10, further comprising: determining when to indicate the first NTN-specific cause in the response based on subscription information of the UE.

12. The method of claim 11 , further comprising: obtaining the subscription information of the UE from another NE.

13. The method of claim 11 , wherein, when the response indicates the first NTN-specific cause, the response further indicates that the UE also lacks TN access entitlement.

14. The method of claim 10, wherein, when the response indicates the second NTN-specific cause, the response further indicates an unavailability time interval.

15. A wireless communication device (102, 110), comprising a transceiver, a processor and computer-readable storage media storing executable instructions for the processor to perform any of the methods recited in claims 1-14, using the transceiver.