Managing connection release in a non-terrestrial network

Abstract

A user equipment (UE) communicates with an access network over a wireless connection, in a first state of a protocol for controlling the wireless connection. The UE receives, from the access network, a request to release the wireless connection, and transitioning to a second state of the protocol upon the receiving of the request, including refraining from transmitting, to the access network, a UE acknowledgement message acknowledging the request to release the wireless connection.

Description

MANAGING CONNECTION RELEASE IN A NON-TERRESTRIAL NETWORKCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 520,591, entitled “Managing Connection Release in a Non-Terrestrial Network,” filed on August 18, 2023. The entire content of the provisional application is hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communication systems, and particularly to communications that involve non-terrestrial network (NTN) elements such as satellites.BACKGROUND

[0003] 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 may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] Generally speaking, a base station operating a cellular radio access network (RAN) communicates with a user equipment (UE) using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which in turn provides logical channels to the Radio Link Control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer.

[0005] The RRC sublayer specifies the RRC IDLE state, in which a UE does not have an active radio connection with a base station and does not store a UE access stratum (AS) context; the RRC CONNECTED state, in which the UE has an active radio connection with the base station; and the RRC INACTIVE to allow a UE to more quickly transition back to the RRC_CONNECTED state due to Radio Access Network (RAN)-level base station coordinationand RAN-paging procedures. Depending on different implementations or scenarios, the base station can configure Small Data Transmission (SDT) for the UE operating in the RRC INACTIVE to transmit one or more small packets.

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

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

[0008] A GSO satellite is stationary relative to the Earth’s surface and can communicate continuously with the same one or several sat-gateways within a satellite-targeted coverage area (e.g., a geographic region or even an entire continent). On the other hand, a non-GSO satellite changes its location relative to the Earth's surface over time and, therefore, at different times, can communicate only temporarily with one or several serving sat-gateways. Generally speaking, an NTN is designed to ensure service and feeder link continuity between successive serving sat- gateways, with sufficient time to proceed with mobility anchoring and handover.

[0009] Further, 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 frequency conversion and amplification, and not change the waveform signal. For a regenerative payload implementation, a satellite can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and coding / modulation. This approach is effectively equivalent to implementing most of the functions of a base station, e.g., a gNB.

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

[0011] Compared to terrestrial network (TN) communications, NTN communications generally have a very long latency due to the service link (i.e., the link between the UE and satellite) and the feeder link (i.e., the link between the satellite and base station). When the UE in an idle state (e.g., the UE operates in the RRC IDLE state without a UE AS context) initiates data transmission in an NTN, the UE has to perform several procedures with a base station and a core network to communicate application data with an application server. These procedures can include a service request procedure, RRC connection establishment procedure, non-access stratum (NAS) authentication procedure, NAS security command procedure, RRC security command procedure, RRC reconfiguration procedures, etc. The UE and the base station and / or the core network exchange messages, which takes significant amounts of time. When the base station detects data inactivity for the UE operating in the RRC CONNECTED state, the base station can suspend the active radio connection with the UE by transitioning the UE to the RRC INACTIVE state or transitioning the UE to the RRC IDLE state with a suspended RRCconnection (in which case the UE in the RRC IDLE stores a UE AS context). When the UE has application data to send, the TE can perform an RRC connection resume procedure (i.e., a single RRC procedure) with the base station to resume the suspended active radio connection and transition to the RRC CONNECTED state. The ETE communicates the application data immediately upon completing the RRC connection resume procedure.

[0012] When a UE in the RRC INACTIVE state or the RRC IDLE state with a suspended radio connection initiates an RRC connection resume procedure for uplink data transmission or periodic RAN notification (RNA) update, the UE starts a timer (e.g., T319 or T300). If the UE successfully completes the RRC connection resume procedure with the base station, the UE stops the timer. However, if the timer expires before the UE completes the RRC connection resume procedure, the UE releases the UE AS context and transitions to the RRC IDLE. In an NTN, as a satellite such an NGSO satellite moves along a specified orbit, for, the coverage area of the satellite beam may move and cover different portions of a geographic area due to the orbital movement of the satellite. As a consequence, the UE located in this geographic area may experience a situation of discontinuous coverage, due to, e.g., sparse satellite constellation deployment. When this is the case, the UE in the NTN can lose coverage for a long period of time (e.g., tens of minutes to hours) due to the discontinuous coverage.

[0013] In some cases, the UE in the NTN can initiate the RRC connection resume procedure while the UE is out of coverage due to the time-discontinuous coverage. The RRC connection resume procedure triggers a cell search. As the UE is out of coverage due to the discontinuous coverage, the UE cannot find a suitable cell in the NTN. Thus, the cell search results only in the UE expending battery power. Moreover, a certain timer expires when the UE fails the RRC connection resume procedure. Upon expiry of this timer, the UE releases the UE AS context and transitions to the RRC IDLE, which will cause a long delay in transmitting data the next time the UE in coverage establishes a connection, because the UE has to perform the several messageintensive procedures to reestablish the connection.

[0014] While the UE communicates with the base station (i.e., the UE operates in a connected state or performs small data transmission (SDT) with the base station), the UE can receive an RRC release message (e.g., RRCRelease) from the base station. In accordance with the 3GPPspecifications, the UE delays transitioning to an idle state (e.g., RRC IDLE state) or an inactive state (e.g., RRC INACTIVE state) for a fixed period of time, 60 ms, from the moment the RRC release message was received, so as to ensure that the UE transmits an acknowledgement to the base station to acknowledge receipt of the RRC release message. However, when the UE communicates with the base station via a satellite, this delay may not be sufficiently long for the UE to transmit an acknowledgement of the RRC release message. As a result, the delay results only in the UE expending battery power. It is not clear how the UE or RAN can select an appropriate time period to ensure that the UE can send an acknowledgment of the RRC release message in time before transitioning to the idle or inactive state.SUMMARY

[0015] An example embodiment of the techniques of this disclosure is a method for managing a wireless connection with an access network. The method is implemented in a user equipment (UE) and comprises communicating with the access network over the wireless connection, in a first state of a protocol for controlling the wireless connection; receiving, from the access network, a request to release the wireless connection; and transitioning to a second state of the protocol upon the receiving of the request, including refraining from transmitting, to the access network, a UE acknowledgement message acknowledging the request to release the wireless connection.

[0016] Another example embodiment of the techniques of this disclosure is a method for managing a wireless connection with an access network. The method is implemented in a user equipment (UE) and comprises communicating with the access network over the wireless connection, in a first state of a protocol for controlling the wireless connection; receiving, from the access network, a request to release the wireless connection; and transitioning to a second state of the protocol according to one of: (i) immediately upon the receiving of the request, (ii) immediately after transmitting, to the access network, an uplink (UL) acknowledgement message acknowledging the request to release the wireless connection, or (iii) after a delay selected based on one or more of the parameters related to the wireless connection.

[0017] Still another example embodiment of these techniques is a wireless communication method performed by a UE configured to communicate with an NTN. The method comprises determining that the UE is out of an NTN coverage and refraining from seeking to reconnect to the NTN until determining the UE is in the NTN coverage.

[0018] Still another example embodiment of these techniques is a UE comprising a transceiver; and processing hardware configured to implement the method above.

[0019] Still another example embodiment of these techniques is wireless communication method performed by a RAN node connected to a UE via an NTN. The method includes determining to suspend a radio connection with the UE upon detecting an upcoming exit out of NTN coverage period during which the RAN node cannot communicate with the UE via the NTN; obtaining a timer value to be used by the UE for waiting before attempting to reconnect to the RAN node, the timer value exceeding an estimated duration of the upcoming out-of-coverage period; and transmitting, to the UE, an RRC release message including the timer value.

[0020] Another example embodiment of these techniques is a RAN node comprising processing hardware configured to implement the method above.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the detailed description, explain these embodiments.

[0022] Fig. 1 A is a block diagram of an example wireless communication system in which a user device and one or more base stations operating in an NTN control implement the techniques of this disclosure for transitioning between connected and idle or inactive states;.

[0023] Fig. IB is a block diagram of an example base station in which a centralized unit (CU) and a distributed unit (DU) operate in the system of Fig. 1A;

[0024] Fig. 2A is a block diagram of an example protocol stack according to which the UE of Fig. 1 A communicates with base stations;

[0025] Fig. 2B is a block diagram of an example protocol stack according to which the UE of Fig. 1 A communicates with a CU and a DU;

[0026] Fig. 3A is a block diagram of an example NTN node with transparent payload implementation.

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

[0028] Fig. 4A illustrates an exemplary user plane protocol stack for use with the architecture of Fig. 3A;

[0029] Fig. 4B illustrates an exemplary control plane protocol stack for use with the architecture of Fig. 3 A;

[0030] Fig. 5 illustrates an example scenario in which a UE has satellite coverage during certain time periods separated by intervals of non-coverage.

[0031] Fig. 6A is a messaging diagram of an example scenario in which a UE transitions receives a command to release the radio connection with the RAN, transmits an uplink acknowledgement, and transitions to the inactive or idle state without waiting for the downlink acknowledgement;

[0032] Fig. 6B is a messaging diagram of an example scenario in which a UE transitions receives a command to release the radio connection with the RAN and transitions to the inactive or idle state without transmitting an uplink acknowledgement;

[0033] Fig. 7A is a flow diagram of an example method that includes transitioning to the inactive or idle state after acknowledging, in the uplink direction, a command from the RAN but without waiting for a downlink acknowledgement of the uplink acknowledgment, which can be implemented in the UE of Fig. 1A;

[0034] Fig. 7B is a flow diagram of an example method that includes transitioning to the inactive or idle state without transmitting an uplink acknowledgment, which can be implemented in the UE of Fig. 1A;

[0035] Fig. 7C is a flow diagram of an example method that includes determining whether to implement the steps of Fig. 7A or 7B based on whether the connection release message was received via a satellite;

[0036] Fig. 7D is a flow diagram of an example method that includes transitioning to the inactive or idle state after a certain amount of time after receiving a command to release the radio connection, which can be implemented in the UE of Fig. 1A;

[0037] Fig. 8A is a flow diagram of an example method that includes selecting, based on the type of the satellite, an amount of time before transitioning to the inactive or idle state after receiving a command from the RAN via the satellite, which can be implemented in the UE of Fig- 1A;

[0038] Fig. 8B is a flow diagram of an example method similar to that of Fig. 8A, but in which the UE selects between two types of satellites;

[0039] Fig. 9A is a flow diagram of an example method that includes transitioning to the inactive or idle state in response to detecting a radio link failure during a delay period that begins when the UE receives, from the RAN, a command to release the radio connection, which can be implemented in the UE of Fig. 1A;

[0040] Fig. 9B is a flow diagram of an example method that includes disabling radio link monitoring after the UE receives, from the RAN, a command to release the radio connection, and waiting for a certain period of time before transitioning to the inactive or idle state, which can be implemented in the UE of Fig. 1A;

[0041] Fig. 9C is a flow diagram of an example method that includes refraining from detecting radio link monitoring after the UE receives, from the RAN, a command to release the radio connection, and waiting for a certain period of time before transitioning to the inactive or idle state, which can be implemented in the UE of Fig. 1A;

[0042] Fig. 10 is a flow diagram of an example method that includes determining whether the UE should initiate a connection reestablishment procedure in response to a radio link failure, which can be implemented in the UE of Fig. 1A;

[0043] Fig. 11 A is a flow diagram of an example method that includes selecting, based on the type of the satellite, an amount of time before releasing resources for a UE and after sending a command to the UE to release the radio connection, which can be implemented in the RAN of Fig. 1A;

[0044] Fig. 1 IB is a flow diagram of an example method similar to that of Fig. 11 A, but in which the RAN selects between two types of satellites;

[0045] Fig. 12 is a flow diagram of an example method that includes releasing resources for a UE after a certain amount of time has elapsed since transmitting a command to release the radio connection, which can be implemented in the RAN of Fig. 1A;

[0046] Fig. 13 A is a flow diagram of an example method that includes releasing resources for a UE after transmitting a command to release the radio connection a certain number of times, which can be implemented in the RAN of Fig. 1 A;

[0047] Fig. 13B is a flow diagram of an example method that includes transmitting a command to the UE to release the radio connection a first number of times, and releasing the resources for the UE after a second number of transmissions of the command, which can be implemented in the RAN of Fig. 1A;

[0048] Fig. 14 is a flow diagram of an example method that includes determining whether to include, in the connection release command for a UE, an amount of time by which the UE is to delay the transition to the inactive or idle state, which can be implemented in the RAN of Fig. 1A; and

[0049] Figs. 15A and 15B are flow diagrams of example methods that include determining whether to disconnect from the RAN immediately or after a delay depending on whether the connection release message includes a delay value, which can be implemented in the UE of Fig. 1A.DETAILED DESCRIPTION OF THE DRAWINGS

[0050] As discussed in more detail below, a UE can use the techniques of this disclosure to determine the timing of transitioning states of a protocol for controlling radio resources between the UE and the RAN. One or more RAN nodes can use the techniques of this disclosure to determine how to configure the UE for transitioning between states, and to determine whether the RAN should release resources for the UE.

[0051] Referring first to Fig. 1A, an example wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 can operate in a RAN 105 connected to the core network (CN) 110. The CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160, for example. The CN 110 can also be implemented as a sixth generation (6G) core in another example.

[0052] 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. As discussed below, the base stations 104 and 106 can be associates with respective satellites, and the RAN 105 can be at least partially implemented as an NTN.

[0053] In general, the RAN 105 can include any number of 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 5GNR (or simply, “NR”) or E-UTRA air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., SI 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.

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

[0055] As illustrated in Fig. 1A, the base station 104 supports a cell 124, and the base station 106 supports a cell 126. Note that cell 124 has a shape corresponding to the footprint of the satellite beams, which unlike cell 126, can project on different areas at different times. 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 base stations supporting NR cells and / or EUTRA cells.

[0056] 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 RRC INACTIVE or RRC IDLE state of the RRC protocol.

[0057] The base station 106 is equipped with processing hardware 140 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory (CRM) storing instructions that the one or more general -purpose processors execute.Additionally or alternatively, the processing hardware 140 can include special -purpose processing units. According to an embodiment illustrated in Fig. 1 A, the processing hardware 140 includes a processor 142 to process data that the base station 106 will transmit in the downlink direction, or data received by the base station 106 in the uplink direction. Theprocessing hardware 140 also includes a transceiver 144 configured to transmit data in the downlink direction and to receive data in the uplink direction. The processing hardware 140 further includes computer-readable medium storing instructions executable by the processor 132, including an RRC controller 148 configured to implement the techniques of the disclosure. The base station 104 can include generally similar components.

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

[0059] Fig. IB depicts an example distributed or disaggregated implementation of any one or more of the base stations 104, 106. In this implementation, the base station 104, 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general -purpose processors (e g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general- purpose processor(s), and / or special-purpose processing units. For example, the CU 172 can include a PDCP controller, an RRC controller and / or an RRC inactive controller. In some implementations, the CU 172 can include a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures. In further implementations, the CU 172 does not include an RLC controller.

[0060] Each of the DUs 174 also includes processing hardware that can include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine- readable instructions executable on the one or more general-purpose processors, and / or specialpurpose processing units. For example, the processing hardware can include a MAC controllerconfigured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and / or an RLC controller configured to manage or control one or more RLC operations or procedures. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0061] In some embodiments, the RAN 105 supports Integrated Access and Backhaul (IAB) functionality. In some implementations, the DU 174 operates as an lAB-node, and the CU 172 operates as an lAB-donor. In some embodiments, the RAN 105 supports Non-Terrestrial Network (NTN) functionality.

[0062] In some implementations, the CU 172 can include a logical node CU-CP 172A that hosts the control plane part of the PDCP protocol of the CU 172. The CU 172 can also include logical node(s) CU-UP 172B that hosts the user plane part of the PDCP protocol and / or Service Data Adaptation Protocol (SDAP) protocol of the CU 172. The CU-CP 172A can transmit control information (e.g., RRC messages, Fl application protocol messages), and the CU-UP 172B can transmit the data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0063] The CU-CP 172 A can be connected to multiple CU-UP 172B through the El interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU-CP 172A through the El interface. The CU-CP 172A can connect to one or more DU 174s through an Fl-C interface. The CU-UP 172B can connect to one or more DU 174 through the Fl-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 can connect to multiple CU-UP 172B under the control of the same CU-CP 172A. In such implementations, the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172A using Bearer Context Management functions.

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

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

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

[0067] 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. 2A) 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.

[0068] Fig. 2B illustrates, in a simplified manner, an example protocol stack 250, which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split as shown by the radio protocol stack 250 in Fig. 2B. The CU at any of the base stations 104 or 106 can hold all the control and upper layer functionalities (e.g., RRC 214, SDAP 212, NR PDCP 210), while the lower layer operations (e.g., NR RLC206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connection to a5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP212 and SRBs to RRC 214.

[0069] Fig. 3A illustrates a certain type of NTN deployment referred to as transparent payload architecture, which involves a satellite gateway 302 and a “transparent” satellite 304 for extending the range of the Uu interface. The satellite 304 implements a frequency conversion and a Radio Frequency (RF) amplifier in both the uplink and downlink directions. The satellite function is similar to that of an analogue RF repeater. As a result, the satellite 304 repeats the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the service link (between the satellite and the UE) in the downlink direction and vice versa in the uplink direction. The Satellite Radio Interface (SRI) on the feeder link is the Uu, and the NTN gateway 302 supports all necessary functions to forward the signal of the Uu interface. The NTN gateway 302 can be placed at the same site where the base station (e.g., eNB, gNB) 104 locates, 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. Fig. 3B illustrates the case where two different satellites (304 and 306) are connected to the same base station 104 via the same NTN gateway 302, and these two satellites (304 and 306) are covering the Earth surface using two different Physical Cell IDs (PCIs).

[0070] The NTN user plane protocol stack involving the UE 102, the satellite 304, the NTN gateway 302, the NR base station (i.e., gNB) 104, and the UPF 114 is illustrated in Fig. 4A. The diagram of the NTN user plane protocol stack is similar to that of the terrestrial network (TN), with the addition of two new nodes, the satellite 304 and the NTN gateway 302, placed in the middle of the NR-Uu interface. The NTN control plane protocol stack illustrated in Fig. 4B is also similar to that of the terrestrial network.

[0071] In terms of the satellite moving pattern, there are three types of service links that are supported in NTN: (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 of time and a different geographic area during another period (e.g., the case of LEO / MEO satellites capable of usingsteerable 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).

[0072] With LEO / MEO satellites, the eNB can provide either quasi -Earth-fixed cell coverage or Earth-moving cell coverage. With GEO satellites, the eNB can provide Earth fixed cell coverage.

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

[0074] Fig. 5 illustrates an example scenario 500 in which the UE 102 located in a certain geographical area may experience discontinuous coverage, due to e.g., a sparse satellites constellation deployment. In the scenario, the LEO satellite 304 serves the UE 102 from tl to t2, and another LEO satellite 306 serves the UE 102 from t3 to t4. In the period between t2 to t3, the UE 102 does not have service of any satellite or any terrestrial base station and therefore is out of coverage. Typically, when a UE loses coverage by a serving cell, the UE starts searching for other cells and then camps on a suitable cell.

[0075] However, in the example illustrated in Fig. 5, even if the UE 102 starts searching for other cells immediately after t2, the UE 102 cannot find a cell. The cell search can last for a long time, as the time period between t2 to t3 can vary from tens of minutes to hours. Therefore, the cell search causes unnecessary power consumption in the UE 102. To reduce power consumption at the UE 102 in such scenarios as the one depicted in Fig. 5, the UE 102 may not be required to perform the cell search and can deactivate the Access Stratum (AS) functions during the period when the UE is not within the area of coverage of a satellite. In some implementations, the UE 102 has knowledge of when the UE 102 will be outside the area of coverage, and when the UE 102 will be within an area of coverage again, in order to activate its cell search or AS functions shortly before the UE 102 enters the area of coverage of another NTN cell. For example, theNTN can broadcast system information with ephemeris information which provides the constellation and trajectory / movement information of the serving and the neighboring satellites, which helps the UE 102 to predict or at least estimate when the UE 102 will be within or outside the NTN coverage. In addition to the ephemeris information, the UE 102 may use other information to estimate / predict coverage of an NTN cell more precisely.

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

[0077] Next, several example scenarios that involve several components of Fig. 1A and relate to connection release are discussed next with reference to Figs. 6A and 6B.

[0078] Referring first to Fig. 6A, in an example scenario 600A, the base station 104 includes a CU 172 and a DU 174 along with a satellite 304. The base station 104 in this scenario suspends a radio connection between the UE 102 and base station 104. The UE 102 initially operates 602 in an inactive state (e.g., RRC IDLE state) or connected state (e.g., RRC CONNECTED state) and communicates 610 with the DU 174 via the satellite 304, e.g., in accordance with a DU configuration, and communicates 610 with the CU-CP 172A and / or CU-UP 172B via the DU 174 and satellite 304, e g., in accordance with a CU configuration. In some implementations, the UE 102 operating 602 in the inactive state performs small data transmission (SDT) to communicate with the base station 104.

[0079] In some implementations, the DU configuration includes configuration parameters related to operations of RLC, MAC, and / or PHY protocol layers (e.g., REC 206B, MAC 204B and / or PHY 202B), that the UE 102 and the DU 174 use to communicate while the UE 102 operates in the connected state. In some implementations, the DU configuration can be a CellGroupConfig IE or include the configuration parameters include configuration parameters in a CellGroupConfig IE, as defined in 3 GPP specification 38.331. In other implementations, theDU configuration can include configuration parameters in a RadioResourceC onfigDedicated- NB-r or RadioResourceConfigDedicated IE as defined in 3GPP specification 36.331.

[0080] In some implementations, the CU configuration includes configuration parameters such as PDCP configuration parameters, radio bearer configuration(s) (e.g., SRB and / or DRB configuration(s), and / or measurement configuration(s). In one implementation, the CU configuration includes a RadioBearerConfig IE and / or MeasConfig IE(s) defined in 3GPP specification 38.331. In another implementation, the CU configuration includes configuration parameters in the RadioBearerConfig IE and / or MeasConfig IE. In yet another implementation, the CU configuration includes SRB-ToAddMod IE(s), DRB-ToAddMod IE(s) and / or MeasConfig IE(s) in the RadioResourceConfigDedicated-NB-vV or RadioResourceConfigDedicated IE .

[0081] While the UE 102 communicates with the base station 104, the CU-CP 172A can determine 640 to suspend a radio connection between the UE 102 the base station 104, based on data inactivity of the UE 102 (i.e., when the UE 102 in the connected state has no data activity with the base station 104 during a certain period of time). In some implementations, the base station 104 transitions the UE 102 to an inactive state (e.g., the RRC INACT1VE state, or RRC IDLE state with a UE AS context stored) to suspend the radio connection. In some implementations, while the UE 102 communicates with the base station 104, the UE 102 determines or detects data inactivity and transmits, to the DU 174, UE assistance information (e.g., a UEAssistancelnformation message) indicating that the UE 102 prefers or requests to transition to the inactive state. In turn, the DU 174 transmits 622 a UL RRC Message Transfer message including the UE assistance information to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the UE assistance information. In other implementations, the DU 174 can perform data inactivity monitoring for the UE 102. The CU-CP 172 A can transmit a CU-to-DU message (e.g., a UE Context Setup Request message or a UE Context Modification Request message) to the DU 174 to request or command the DU 174 to perform the data inactivity monitoring. When the DU 174 detects or determines that the UE 102 is in data inactivity during the monitoring, the DU 174 can transmit 630 an inactivity notification (e.g., UE Inactivity Notification message) to the CU-CP 172A. Thus, the CU-CP 172A candetermine that the UE 102 is in data inactivity based on the inactivity notification received from the DU 174. In yet other implementations, the CU-UP 172B can perform data inactivity monitoring for the UE 102. The CU-CP 172A can transmit a CP-to-UP message (e.g., a Bearer Context Setup Request message or a Bearer Context Modification Request message) to the CU- UP 172B to request or command the CU-UP 172B to perform the data inactivity monitoring. When the CU-UP 172B detects or determines that the UE 102 is in data inactivity during the monitoring, the CU-UP 172B can transmit 632 an inactivity notification (e.g., Bearer Context Inactivity Notification message) to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the inactivity notification received from the CU-UP 172B. In various implementations, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the UE assistance information, receiving 630 the inactivity notification, and / or receiving 632 the inactivity notification from the CU-UP 172B.

[0082] After a certain period of data inactivity, the CU-CP 172A can determine that neither the CU 172 (i.e., the CU-CP 172A and / or the CU-UP 172B) nor the UE 102 has transmitted any data in the downlink direction or the uplink direction, respectively, during the certain period. In response to the determination, the CU-CP 172 A can determine 640 to transition the UE 102 to the inactive state.

[0083] In response to or after determining that the UE 102 is in data inactivity for the corresponding period of time, the CU-CP 172A sends 642 to the CU-UP 172B a CP-to-UP message (e.g., Bearer Context Modification Request message) to suspend data transmission for the UE 102. In response, the CU-UP 172B suspends data transmission for the UE 102 and sends 644 an UP-to-CP message (e.g., Bearer C ontext Modification Response message) to the CU-CP 172A. Alternatively, in response to or after determining that the UE 102 is in data inactivity for the corresponding period of time, the CU-CP 172A sends 642 to the CU-UP 172B a CP-to-UP message (e.g., Bearer Context Release Command message) to release resources configured for the UE 102. In response, the CU-UP 172B releases resources configured for the UE 102 and sends 644 an UP-to-CP message (e.g., Bearer C ontext Release Complete message) to the CU-CP 172A.

[0084] In response to determining to transition the UE 102 to the inactive or idle state, the CU-CP 172A can generate an RRC release message (e.g., RRCRelease message or RRCConnectionRelease message) to transition the UE 102 to the inactive or idle state. In some implementations, the CU-CP 172A includes a suspend configuration (e.g., SnspendConfig 'iE)' for suspending data transmission for the UE 102. The CU-CP 172A then sends 650 to the DU 174 a UE Context Release Command message, which includes the RRC release message. In turn, the DU 174 transmits 652 the RRC release message to the UE 102. The RRC release message instructs the UE 102 to transition to the idle or inactive state.

[0085] When the UE 102 receives 652 the RRC release message, the UE 102 delays transitioning to the idle or inactive state and transmits 654, to the DU 174, a UL acknowledgement (ACK) to acknowledge receipt of the RRC release message. Upon receiving 654 the UE ACK, the DU 174 determines 660 that the UE 102 receives the RRC release message and transmits 662 a UE Context Release Complete message to the CU-CP 172A in response to the UE Context Release Command message. If the CU-CP 172A determines to transition the UE 102 to the idle state, the CU-CP 172A releases a UE context of the UE 102 upon receiving the UE Context Release Complete message 662. For example, the UE context can include configuration parameters and / or resources that the CU-CP 172A configured for the UE 102 to communicate with the DU 174. If the CU-CP 172A determines to transition the UE 102 to the inactive state, the CU-CP 172 A stores the UE context after transmitting the UE Context Release Command message. After receiving the UE Context Release Complete message, the CU-CP 172A determines that the UE 102 transitions to the idle or inactive state (i.e., the UE 102 successfully receives the RRC release message).

[0086] Thus, both the UE 102 and the base station 104 have the same understanding of the state of the UE 102, which avoids a state mismatch problem between the UE 102 and the base station 104.

[0087] In some alternative implementations, the DU 174 transmits 662 the UE Context Release Complete message in response to the UE Context Release Command message regardless of whether receiving the UL ACK 654.

[0088] After transmitting 654 the UL ACK message, the UE 102 transitions 670 to the idle or inactive state in response to the RRC release message, without waiting to receive, from the DU 174, a DL ACK corresponding to the UL ACK. The UE 102 then operates 698 in the idle or inactive state. In some implementations, the UL ACK is a Hybrid Automatic Repeat request (HARQ) acknowledgement. In other implementations, the UL ACK is an RLC ACK (e.g., a RLC Control PDU). In some implementations, the DL ACK is a HARQ ACK. In other implementations, the DL ACK is an RLC ACK. In some implementations, the UE 102 transitions 670 to the idle or inactive state immediately after transmitting the UL ACK 654, to save battery power at the UE 102.

[0089] In some implementations, the UE 102 stores a UE access stratum (AS) context (e.g., UE Inactive AS context) in response to receiving 652 the RRC release message that instructs the UE 102 to suspend data transmission or transition to the inactivate state. The UE AS context includes configuration parameters, security key(s), and / or measurement configuration(s) that the UE 102 uses to communicate with the base station 104 before receiving the RRC release message. For example, the UE AS context configuration parameters may be included in the DU configuration. The CU-CP 172A also stores the UE AS context for the UE 102 operating in the inactive state. In some implementations, the RRC release message includes a periodic RAN notification area (RNA) timer value. The UE 102 starts a periodic RNA timer with the periodic RNA timer value after (e.g., in response to) receiving the RRC release message. In some implementations, the CU-CP 172A can start a network timer with a timer value, similar to the periodic RNA timer. Typically, the timer value of the network timer is larger than or equal to the periodic RNA timer value. In some implementations, if the CU-CP 172A connects the UE 102 before the network timer expires, the CU-CP 172A can restart or stop the network timer. If the network timer expires, the CU-CP 172A may determine that the UE 102 transitions to an idle state (e.g., the RRC IDLE without a stored UE AS context) and releases the UE AS context. In some alternative implementations, the CU-CP 172A does not start or use the network timer and stores the UE AS context without time limit. In yet other implementations, the RRC release message does not include a periodic RNA timer value. In such implementations, the base station 104 does not start the network timer and stores the UE AS context without a time limit.

[0090] In some implementations, the DU 174 releases a UE context of the UE 102 in response to the determination 660. In other words, after receiving 650 the UE Context Release Command message, the DU 174 refrains from releasing the UE context until the determination 660. For example, the UE context includes configuration parameters and / or resources that the DU 174 configured for the UE 102 to communicate with the DU 174. As another example, the UE context includes transport layer configuration that the DU 174 configured for communicating data of the UE 102 with the CU-UP 172B. The transport layer configuration can include an IP address of the CU-UP 172B, a first tunnel ID (TEID) of the CU-UP 172B, and a second TEID of the DU 174.

[0091] In some implementations, if the DU 174 does not receive the UL ACK after a certain period of time has elapsed, the DU 174 releases the UE context and / or transmits the UE Context Release Complete message. In some implementations, the DU 174 receives a time period value configuring the time period from the CU-CP 172A. In other implementations, the DU 174 receives the time period value from an operation, administration and maintenance (0AM) node. In yet other implementations, the time period value is a predetermined value that the DU 174 stores in non-volatile memory.

[0092] In some alternative implementations, the CU-CP 172A can include the RRC release message in a l)L RRC Message Transfer message instead of the UE Context Release Command message and transmits the DL RRC Message Transfer message to the DU 174. In turn, the DU 174 transmits 652 the RRC release message to the UE 102. In such cases, the CU-CP 172A still transmits a UE Context Release Command message not including an RRC release message to the DU 174, as described above.

[0093] In some implementations, the DU 174 establishes a connection with the NTN gateway to communicate data of the UE 102 in or before the event 610. In such implementations, the DU 174 can perform a connection release procedure with a NTN gateway controlling the satellite 304 to release the connection, after receiving the UE Context Release Command message, transmitting the RRC release message to the UE 102, or receiving an acknowledgement for a PDU, including the RRC release message, that the DU 174 transmits to the UE 102. For example, the PDU is a MAC PDU and the acknowledgement is a hybrid automatic repeat request(HARQ) acknowledgement. In another example, the PDU is a RLC PDU and the acknowledgement is a RLC acknowledgement. In other implementations, when the DU 174 receives the UE Context Release Command message or transmits the RRC release message, the DU 174 performs the connection release procedure after a predetermined time.

[0094] In some implementations, the RRC layer (e.g., RRC 214) of the UE receives the RRC release message (e.g., an RRC release message) from a PDCP layer (e.g., PDCP 210). In some implementations, a RLC layer (e.g., RLC 206B) of the UE transmits the UL ACK. In some implementations, after transmitting UL ACK, the RLC layer transmits an indication to the RRC layer to indicate that an acknowledgement for the RRC release message has been transmitted. In other implementations, the RLC layer transmits an indication to the PDCP layer to indicate that an acknowledgement for a PDCP PDU including the RRC release message has been transmitted. The PDCP layer transmits an indication to the RRC layer to indicate that an acknowledgement for the RRC release message has been transmitted. In other implementations, a physical layer (e.g., PHY 202B) of the UE transmits the UL ACK. The physical layer transmits an indication to the RRC layer directly or via one or more protocol layers to indicate that an acknowledgement for the RRC release message has been transmitted. The protocol layer(s) includes a MAC layer, the RLC layer and / or the PDCP layer.

[0095] Referring next to Fig. 6B, a scenario 600B is generally similar to the scenario 600A. The differences between the scenarios 600B and 600A are discussed below.

[0096] The UE 102 transitions 671 to the idle or inactive state in response to the RRC release message, without transmitting a UL ACK to acknowledge receipt of the RRC release message. In some implementations, the UE 102 transitions 671 to the idle or inactive state immediately in response to the RRC release message. Thus, the UE 102 does not delay transitioning to the idle or inactive state upon receiving the RRC release message, which saves battery power of the UE 102. In some implementations, the DU 174 releases the UE context when / after a time period of a certain duration has elapsed as described above. In other implementations, the DU 174 transmits 652 the RRC release in multiple transmissions to the UE 102 to avoid the situation in which the UE 102 fails to receive the RRC release message. In such cases, the DU 174 can release the UE context after transmitting the multiple transmissions. In some implementations,the multiple transmissions are HARQ (re)transmissions. In other implementations, the multiple transmissions are transmissions of RLC PDUs each including the RRC release message.

[0097] Next, several example methods that can be implemented in a UE (e.g., the UE 102), a RAN node such as a base station (BS), a DU of a BS, or a CU of a BS, or a RAN (e.g., the RAN 105) are discussed with reference to Figs. 7A-15B. 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. At least some of the description of Figs. 6A and 6B can also apply to Figs. 7A-14.

[0098] Generally speaking, similar events in Figs. 6A-15B are labeled with similar reference numbers that share two least significant digits, with the differences discussed below where appropriate. For example, event 610 is generally similar to block 710, block 752 is similar to block 952 and 1152, and block 1340 is similar block 1440.

[0099] Referring first to Fig. 7A, a method 700A can be implemented in a UE (e.g., the UE 102) and includes determining when to transition to an idle or inactive state upon receiving a connection release message.

[0100] The method 700A begins at block 710, where the UE communicates with a RAN (e.g., events 602, 610). At block 752, the UE receives from the RAN a connection release message, instructing the UE to transition to an idle or inactive state with the RAN (e.g., event 652). At block 754, the UE transmits a UE acknowledgement to the RAN to acknowledge receipt of the connection release message (e.g., event 654). At block 770, the UE transitions to the idle or inactive state in response to the connection release message, after transmitting the UE acknowledgement without waiting for a DL acknowledgement of the UE acknowledgement (e.g., event 670). In other words, upon receiving the connection release message (e.g., an RRC release message), the UE refrains from transitioning or will not transition to the idle or inactive state until transmitting the UL acknowledgement. In some implementations, the UE transitions to the idle or inactive state immediately after transmitting the UL acknowledgement. In other implementations, the UE transitions to the idle or inactive state after a time period of a relativelyshort duration after transmitting the UL acknowledgement. For example, the short duration is below 10, 20, 30, 40 or 50 ms.

[0101] Fig. 7B is a flow diagram of an example method 700B, similar to the method 700A, except that the method 700B includes block 771 instead of blocks 754 and 770.

[0102] At block 771, the UE transitions to the idle or inactive state in response to the connection release message without transmitting an UL acknowledgement to acknowledge receipt of the connection release message (e g., event 671). In some implementations, upon receiving the connection release message, the UE refrains from transmitting an UL acknowledgement to acknowledge receipt of the connection release message.

[0103] Fig. 7C is a flow diagram of an example method 700C, similar to the methods 700A and 700B, except that the method 700C includes blocks 755 and 772. At block 705, the UE determines whether the UE receives the connection release message via a satellite. If the UE determines that the UE receives the connection release message via a satellite at block 705, the flow proceeds to blocks 754 and 770 or block 707. Otherwise, if the UE determines that the UE receives the connection release message via a terrestrial network (i.e., not via a satellite) at block 705, the flow proceeds to block 772. At block 772, transitions to the idle or inactive state after a time period of a predetermined duration has elapsed in response to the connection release message.

[0104] Fig. 7D is a flow diagram of an example method 700D, similar to the method 700A, except that the method 700D includes block 773 instead of blocks 754 and 770. At block 773, the UE transitions to the idle or inactive state after a time period of a certain duration has elapsed in response to the connection release message, where the duration is determined or predetermined based on a scheduling offset, one or more round-trip times, and / or number of retransmissions.

[0105] In some implementations, the scheduling offset is a configured scheduling offset (e.g., Koffset). In some implementations, the configured scheduling offset is larger or equal to the sum of a service link RTT and a common TA. In some implementations, the UE receives an RRC message including the scheduling offset from the RAN. For example, the RRC message is anRRC setup message, an RRC connection setup message, an RRC reconfiguration message, an RRC connection reconfiguration message, an RRC resume message, or an RRC connection resume message. In other implementations, the UE receives a MAC control element (CE) including the scheduling offset from the RAN.

[0106] In some implementations, the round-trip time(s) include a round-trip time of a serving link and / or a round-trip time of a feeder link. The UE communicates with the RAN via a satellite and the RAN communicates with the satellite via a ground station. The service link is a link between the UE and the satellite and the feeder link is a link between the satellite and the ground station. In some implementations, the retransmissions are HARQ retransmissions of the RRC release message.

[0107] In some implementations, the duration is determined or predetermined based on one or more additional parameters, in addition to the scheduling offset, round-trip time(s), and / or number of retransmissions. For example, the additional parameter(s) include an additional scheduling offset (e.g., Ki) that the UE receives in a downlink control information (DCI) scheduling a DL transmission including the RRC release message. In some implementations, additional parameter(s) include one or more HARQ feedback (e.g., HARQ negative ACK(s) and / or HARQ ACK). In some implementations, additional parameter(s) include one or more one-way propagation delays.

[0108] In some implementations, the UE determines the duration based on the scheduling offset, round-trip time(s), number of retransmissions, and / or additional parameter(s). In other implementations, the duration is predetermined in a 3GPP specification based on the scheduling offset, round-trip time(s), number of retransmissions, and / or the additional parameter(s). For example, the duration is equal to the sum of at least two one of the scheduling offset, the roundtrip time(s) multiplied by the number of retransmissions, and a time value determined by the additional parameters(s). In another example, the duration is equal to the sum of at least two one of the scheduling offset, the round-trip time(s) multiplied by the number of retransmissions, a time value determined by the additional parameters(s), and / or a tolerance. In yet another example, the duration is equal to or larger than the sum of the scheduling offset and theadditional offset. In yet another example, the duration is equal to or larger than the sum of the scheduling offset, the additional offset and a tolerance.

[0109] Referring now to Fig. 8A, a method 800A can be implemented in a UE (e.g., the UE 102) and includes determining when to transition to an idle or inactive state upon receiving a connection release message.

[0110] The method 800A begins at blocks 810 and 842 similar to blocks 710 and 752, respectively. At block 856, the UE determines whether the UE receives the connection release message via a GEO, MEO or LEO satellite (i.e., the UE is communicating with the RAN via a GEO, MEO or LEO satellite). If the UE determines that the UE receives the connection release message via a GEO satellite at block 856, the flow proceeds to block 874. At block 874, the UE transitions to the idle or inactive state after a period of a first duration has elapsed in response to the connection release message (e.g., event 670). If the UE determines that the UE receives the connection release message via a MEO satellite at block 856, the flow proceeds to block 875. At 875, the UE transitions to the idle or inactive state after a period of a second duration has elapsed in response to the connection release message (e.g., event 670). Otherwise, if the UE determines that the UE receives the connection release message via a LEO satellite at block 856, the flow proceeds to block 876. At block 876, the UE transitions to the idle or inactive state after a period of a third duration has elapsed in response to the connection release message (e.g., event 670).[0U1] In some implementations, the first duration is longer than the second duration and the second duration is longer than the third duration. In some implementations, the first duration, second duration and third durations are predetermined in a 3GPP specification. In other implementations, the UE determines the first, second and third durations as described for Fig. 7D. In some implementations, the RAN sets different scheduling offsets for a GEO satellite, a MEO satellite and a LEO satellite. In some implementations, round-trip times for a GEO satellite, a MEO satellite and a LEO satellite are different. In some implementations, the number retransmission for a GEO satellite, a MEO satellite and a LEO satellite can be the same or different.

[0112] Fig. 8B is a flow diagram of an example method 800B, similar to the method 800A, except that the method 800B includes block 857 instead of block 856. At block 857, the UE determines whether the UE receives the connection release message via a satellite of a first type or a second type. If the UE determines that the UE receives the connection release message via a satellite of the first type at block 857, the flow proceeds to block 874. Otherwise, if the UE determines that the UE receives the connection release message via a satellite of the second type at block 857, the flow proceeds to block 875. In some implementations, the first type is one of GEO, MEO and LEO types and the second type is another one or the other of the GEO, MEO and LEO types.

[0113] In some implementations, the RAN sets different scheduling offsets for a satellite of the first type and a satellite of a second type. In some implementations, round-trip times for a satellite of the first type and a satellite of a second type are different. In some implementations, the number retransmission for a satellite of the first type and a satellite of a second type can be the same or different.

[0114] Examples and implementations described for Figs. 7A-7D can apply to Figs. 8A and 8B.

[0115] Referring now to Fig. 9A, a method 900A can be implemented in a UE (e.g., the UE 102) and includes determining when to transition to an idle or inactive state upon receiving a connection release message.

[0116] The method 900 A begins at block 911, where the UE communicates with a RAN in a connected state. In some implementations, the UE communicates with the RAN via a satellite (e.g., events 602, 610). In other implementations, the UE communicates with the RAN not via a satellite (i.e., the UE communicates with the RAN in a terrestrial network). At block 952, the UE receives from the RAN a connection release message, instructing the UE to transition to an idle or inactive state with the RAN (e.g., event 652). At block 980, the UE delays transitioning to the idle or inactive state for a time period of certain duration in response to the connection release message. At block 981, the UE detects a radio link failure during the time period of the certain duration. At block 982, the UE refrains from initiating an RRC connectionreestablishment procedure in response to the radio link failure. At block 977, the UE transitions to the idle or inactive state in response to the detection before the time period elapses (e g., event 671).

[0117] In some implementations, the UE determines the duration as described above. In other implementations, the duration is predetermined in a 3GPP specification.

[0118] Fig. 9B is a flow diagram of an example method 900B, similar to the method 900A, except that the method 900B includes blocks 983 and 978 instead of blocks 981, 982 and 977. At block 983, the UE disables radio link monitoring in response to receiving the connection release message. In other words, the UE disables the radio link monitoring during the period of a certain duration. Thus, the UE does not detect a radio link failure after disabling the radio link monitoring. The UE performs the radio link monitoring on a link with the RAN while communicating with the RAN at block 911. At block 978, the UE transitions to the idle state or inactive state after the period of a certain duration has elapsed in response to the connection release message. Because the UE does not detect a radio link failure due to disabling the radio link monitoring, the UE can transmit a UL acknowledgement to the RAN to acknowledge receipt of the connection release message. Thus, the RAN can release resources configured for the UE upon receiving the UL acknowledgement. This prevents the RAN from keep resources configured for the UE for a long time.

[0119] Fig. 9C is a flow diagram of an example method 900C, similar to the methods 900A and 900B, except that the method 900C includes block 984 instead of block 983. At block 984, the UE refrains from detecting a radio link failure in response to receiving the connection release message. In other words, the UE does detect a radio link failure during the time period of the certain duration.

[0120] Examples and implementations described above can apply to Figs. 9A-9C.

[0121] Referring now to Fig. 10, a method 1000 can be implemented in a UE (e.g., the UE 102) and includes determining when to transition to an idle or inactive state upon receiving a connection release message.

[0122] The method 1000 begins at block 101 1, where the UE communicates with a RAN in a connected state (e.g., events 602, 610). At block 1004, the UE detects a radio link failure while communicating with the RAN. At block 1006, the UE determines whether the UE is delaying transitioning to an idle or inactive state. If the UE determines that the UE is delaying transitioning to the idle or inactive state at block 1006, the flow proceeds to block 1008. At block, the UE performs actions as described in blocks 981 and 982. Otherwise, if the UE determines that the UE is not delaying transitioning to the idle or inactive state at block 1006, the flow proceeds to block 1010. At block 1010, the UE initiates an RRC connection reestablishment procedure in response to the detection.

[0123] Examples and implementations described above can apply to Fig. 10.

[0124] Referring next to Fig. 11 A, a method 1100A can be implemented in a RAN (e.g., the base station 104, the DU 174 of the base station 104, or the RAN 105) to release resources configured for a UE (e.g., the UE 102).

[0125] The method 1100A begins at block 1110, where the RAN communicates with a UE (e.g., event 610). At block 1152, the RAN transmits a connection release message to the UE, instructing the UE to transition to an idle or inactive state (e.g., event 652). At block 1156, the RAN determines whether the RAN communicates with the UE via a GEO, MEO or LEO satellite. If the RAN determines that RAN communicates with the UE via a GEO satellite at block 1156, the flow proceeds to block 1174. At block 1174, the RAN releases resources configured for the UE in response to transmitting the connection release message, after a time period of a first duration has elapsed. If the RAN determines that RAN communicates with the UE via a MEO satellite at block 1156, the flow proceeds to block 1175. At block 1175, the RAN releases resources configured for the UE in response to transmitting the connection release message, after a time period of a second duration has elapsed. Otherwise, if the RAN determines that RAN communicates with the UE via a LEO satellite at block 1156, the flow proceeds to block 1176. At block 1176, the RAN releases resources configured for the UE in response to transmitting the connection release message, after a time period of a third duration has elapsed.

[0126] In some implementations, the first duration is longer than the second duration and the second duration is longer than the third duration. In some implementations, the first duration, second duration and third durations are predetermined in a 3GPP specification. In other implementations, the RAN determines the first, second and third durations as described for the UE in Fig. 7D. In some implementations, the first, second and third durations in Fig. 11 A may be a bit longer than the first, second and third durations in Fig. 8A, respectively.

[0127] Fig. 1 IB is a flow diagram of an example method 1100B, similar to the method 1100A, except that the method 1100B includes block 1157 instead of block 1156. At block 1157, the RAN communicates with the UE via a satellite of a first type or a second type. If the RAN determines that RAN communicates with the UE via a satellite of the first type at block 1 157, the flow proceeds to block 1174. Otherwise, if the RAN determines that RAN communicates with the UE via a satellite of the second type at block 1157, the flow proceeds to block 1175.

[0128] Examples and implementations described above can apply to Figs. 11A and 1 IB.

[0129] Referring next to Fig. 12, a method 1200 can be implemented in a RAN (e.g., the base station 104, the DU 174 of the base station 104, or the RAN 105) to release resources configured for a UE (e g., the UE 102).

[0130] The method 1200 begins at block 1210, where the RAN communicates with a UE (e.g., event 610). At block 1240, the RAN determines to transition the UE to an idle or inactive state (e.g., event 640). At block 1252, the RAN transmits a connection release message to the UE in response to the determination. At block 1282, the RAN releases resources configured for the UE after a time period of a certain duration has elapsed in response to the connection release message, where the duration is predetermined based on a scheduling offset, one or more roundtrip times, and / or number of retransmissions. Examples and implementations described for the UE in Fig. 7D can apply to the RAN in Fig. 12. In some implementations, the RAN determines the duration as described for the UE in Fig. 7D.

[0131] Examples and implementations described above can apply to Fig. 12.

[0132] Referring next to Fig. 13 A, a method 1300A can be implemented in a RAN (e.g., the base station 104, the DU 174 of the base station 104, or the RAN 105) to release resources configured for a UE (e.g., the UE 102).

[0133] The method 1300A begins at block 1310, where the RAN communicates with a UE. In some implementations, the RAN communicates with the UE via a satellite (e.g., events 602, 610). In other implementations, the RAN communicates with the RAN not via a satellite (i.e., the RAN communicates with the UE in a terrestrial network). At block 1340, the RAN determines to transition the UE to an idle or inactive state (e.g., event 640). At block 1353, the RAN transmits a connection release message N times to the UE in response to the determination, where Nis larger than one (e.g., event 652). In some implementations, Nis 2, 3 or 4. At block 1390, the RAN releases resources configured for the UE after transmitting the connection release message N times in response to the determination.

[0134] Fig. 13B is a flow diagram of an example method BOOB, similar to the method 1300A, except that the method BOOB includes blocks 1355 and 1358.

[0135] At block 1355, the RAN determines whether the RAN communicates with the UE via a satellite when making the determination at block 1340. If the RAN determines that the RAN communicates with the UE via a satellite at block 1355, the flow proceeds to blocks 1353 and 1390. Otherwise, if the RAN determines that the RAN communicates with the UE not via a satellite at block 1355, the flow proceeds to block 1358. At block 1358, the RAN transmits a connection release message AT times to the UE in response to the determination, where 0 < M< N. At block 1385, the RAN releases resources configured for the UE after transmitting the connection release message AT times in response to the determination. In some implementations, the connection release message is an RRC release message.

[0136] Examples and implementations described above can apply to Figs. 13 A and 13B.

[0137] Referring next to Fig. 14, a method 1400 can be implemented in a RAN (e.g., the base station 104, the DU 174 of the base station 104, or the RAN 105) to release resources configured for a UE (e g., the UE 102).

[0138] The method 1400 begins at blocks 1410 and 1440 same as blocks 1310 and 1340 respectively. At block 1455, the RAN determines whether the RAN communicates with the UE via a satellite when making the determination at block 1440. If the RAN determines that the RAN communicates with the UE via a satellite at block 1455, the flow proceeds to block 1445. At block 1445, the RAN includes in a connection release message, a duration value for the time period by which the UE is to delay disconnecting from the RAN. Otherwise, if the RAN determines that the RAN communicates with the UE not via a satellite at block 1455, the flow proceeds to block 1446. At block 1446, the RAN refrains from including, in a connection release message, a duration value for the time period by which the UE would delay disconnecting from the RAN. The flow proceeds to block 1452 from block 1445 as well as block 1446. At block 1452, the RAN transmits the connection release message to the UE in response to the determination.

[0139] Examples and implementations described above can apply to Fig. 13.

[0140] Referring now to Fig. 15 A, a method 1500A can be implemented in a UE (e.g., the UE 102) and includes determining when to transition to an idle or inactive state upon receiving a connection release message.

[0141] The method 1500A begins at blocks 1510, where the UE communicates with a RAN. In some implementations, the UE communicates with the RAN via a satellite (e.g., events 602, 610). In other implementations, the UE communicates with the RAN not via a satellite. At block 1552, the UE receives a connection release message from the RAN (e g., event 652). At block 1559, the UE determines whether the connection release message configures a duration value by which the UE is to delay disconnecting from the RAN. If the UE determines that the connection release message configures a duration value by which the UE to delay disconnecting from the RAN at block 1559, the flow proceeds to block 1586. At block 1586, the UE delays disconnecting from the RAN for a period of time corresponding to the duration value. In other words, the RAN in this case configures the duration value. At block 1592, the UE disconnects from the RAN after the period of time of the indicated duration has elapsed, and in response to the connection release message. In some implementations, the UE transitions to an idle or inactive state after the duration has elapsed in response to the connection release message.Otherwise, if the UE determines that the connection release message does not configure a duration value by which the UE is to delay disconnecting from the RAN at block 1559, the flow proceeds to block 1587. At block 1587, the UE delays disconnecting from the RAN by a period of time of a predetermined duration. At block 1594, the UE disconnects from the RAN after a period of time of the predetermined duration has elapsed in response to the connection release message. In some implementations, the UE transitions to an idle or inactive state after a period of time of the predetermined duration has elapsed in response to the connection release message.

[0142] Fig. 15B is a flow diagram of an example method 1500B, similar to the method 1500A, except that the method 1500B includes block 1595 instead of blocks 1587 and 1594. At block 1595, the UE disconnects from the RAN immediately in response to the connection release message.

[0143] Examples and implementations described above can apply to Fig. 15A and 15B.

[0144] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

[0145] Example 1. A method for managing a wireless connection with an access network, the method implemented in a UE and comprising: communicating with the access network over the wireless connection, in a first state of a protocol for controlling the wireless connection; receiving, from the access network, a request to release the wireless connection; and transitioning to a second state of the protocol according to one of: (i) immediately upon the receiving of the request, (ii) immediately after transmitting, to the access network, an uplink (UL) acknowledgement message acknowledging the request to release the wireless connection, or (iii) after a delay selected based on one or more of the parameters related to the wireless connection.

[0146] Example 2. The method of example 1, wherein the transitioning to the second state of the protocol immediately upon the receiving of the request includes refraining from transmitting, to the access network, a UE acknowledgement message acknowledging the request to release the wireless connection.

[0147] Example 3. The method of example 1, wherein the transitioning to the second state of the protocol immediately after the transmitting of the acknowledgement message includes: refraining from awaiting, from the access network, a DL acknowledgment message acknowledging the UL acknowledgement message.

[0148] Example 4. The method of example 3, wherein the UL acknowledgement message is a HARQ message.

[0149] Example 5. The method of example 3, wherein the UL acknowledgement message is an RLC message.

[0150] Example 6. The method of any of examples 3-5, wherein the transmitting of the UL acknowledgement message includes: transmitting the UL acknowledgement message from an RLC layer of the UE.

[0151] Example 7. The method of example 6, further comprising transmitting, from the RLC layer to a Radio Resource Control (RRC) layer, an indication that the UL acknowledgement message has been transmitted.

[0152] Example 8. The method of example 6, further comprising transmitting, from the RLC layer to a PDCP, an indication that the UL acknowledgement message has been transmitted.

[0153] Example 9. The method of any of examples 3-5, wherein the transmitting of the UL acknowledgement message includes transmitting the UL acknowledgement message from a PHY of the UE.

[0154] Example 10. The method of example 9, further comprising transmitting, from the PHY layer to an RRC layer, an indication that the UL acknowledgement message has been transmitted.

[0155] Example 11. The method of example 1, wherein the transitioning to the second state of the protocol after the delay includes selecting the delay based on one or more of: (i) a configured scheduling offset, (ii) a round-trip time of a link between the UE and a node of the access network, (iii) a number of HARQ retransmissions.

[0156] Example 12. The method of example 1 , wherein the transitioning to the second state of the protocol after the delay includes selecting the delay based on whether the request to release the wireless connection was received from a terrestrial or non-terrestrial node of the access network.

[0157] Example 13. The method of example 1, wherein the transitioning to the second state of the protocol after the delay includes selecting the delay based on a type of a type of a satellite from which the request to release the wireless connection was received.

[0158] Example 14. The method of example 13, wherein the selecting of the delay includes selecting a first duration of the delay in response to determining that the satellite is of a first type; and selecting a second duration of the delay in response to determining that the satellite is of a second type.

[0159] Example 15. The method of example 13, wherein the selecting of the delay includes selecting a first duration of the delay in response to determining that the satellite is a Geostationary Earth Orbit (GEO) satellite; selecting a second duration of the delay in response to determining that the satellite is a MEO satellite; and selecting a third duration of the delay in response to determining that the satellite is a LEO satellite.

[0160] Example 16. The method of any of the preceding examples, wherein the second state of the protocol is an RRC INACTIVE state.

[0161] Example 17. The method of any of examples 1-15, wherein the second state of the protocol is an RRC IDLE state.

[0162] Example 18. The method of any of the preceding examples, further comprising storing a UE AS context in response to the request to release the wireless connection.

[0163] Example 19. The method of example 18, wherein the UE AS context includes one or more of security key or a measurement configuration.

[0164] Example 20. A UE comprising a transceiver and processing hardware configured to implement according to any of the preceding examples.

[0165] Example 21 . A wireless communication method performed by a UE configured to communicate with an NTN, the method comprising: determining that the UE is out of an NTN coverage; and refraining from seeking to reconnect to the NTN until determining the UE is in the NTN coverage.

[0166] Example 22. The wireless communication method of example 21, wherein a UE connection with the NTN is suspended in response to a radio resource control, RRC, release command before the determining that the UE is out of the NTN coverage.

[0167] Example 23. The wireless communication method of example 21 or 22, further comprising: before the determining that the UE is out of an NTN coverage, detecting that leaving of an NTN area is forthcoming; and in response to the detecting, transmitting, to the NTN, UE assistance information.

[0168] Example 24. The wireless communication method of example 23, further comprising: receiving a radio resource control, RRC, release command after the transmitting of the UE assistance information and before the determining that the UE is out of the NTN coverage.

[0169] Example 25. The wireless communication method of example 22, wherein the RRC release command includes a timer value, and the method further comprises: initiating radio resource control, RRC, reconnect procedure after a time interval corresponding to the timer value.

[0170] Example 26. The wireless communication method of example 22, wherein the RRC release command includes a timer value, the method further comprising initiating an RRC reconnect procedure when a time interval corresponding to the timer value expires.

[0171] Example 27. The wireless communication method of any of examples 21-26, wherein the determining that the UE is out of the NTN coverage includes determining that the out of NTN coverage is caused by a discontinuous coverage.

[0172] Example 28. The wireless communication method of any of examples 21-27, wherein the determining that the UE is out of the NTN coverage is performed when the UE operates in an NTN mode.

[0173] Example 29. The wireless communication method of any of examples 21 -28, wherein the UE connection is interrupted due to a radio link failure before the determining the UE is out of the NTN coverage.

[0174] Example 30. The wireless communication method of example 29, further comprising: transitioning to an idle state while out of the NTN coverage.

[0175] Example 31. The wireless communication method of any of examples 21-39, further comprising: terminating an RRC reconnect procedure initiated after the radio link failure when the determining that the UE is out of the NTN coverage occurs.

[0176] Example 32. The wireless communication method of any of examples 21 -31 , further comprising: initiating an NTN connection establishment procedure after the determining the UE is in the NTN coverage.

[0177] Example 33. A wireless communication method performed by RAN node connected to a UE via a non-terrestrial network, NTN, the method comprising: determining to suspend a radio connection with the UE upon detecting an upcoming exist out of NTN coverage period during which the RAN node cannot communicate with the UE via the NTN; obtaining a timer value to be used by the UE for waiting before attempting to reconnect to the RAN node, the timer value exceeding an estimated duration of the upcoming exit out of coverage period; and transmitting, to the UE, a radio resource control, RRC, release message including the timer value.

[0178] Example 34. The wireless communication method of example 22, further comprising estimating the upcoming exit out of coverage period based on UE’s location and satellite-related information.

[0179] Example 35. A wireless communication device comprising a transceiver, a processor, and computer-readable storage media storing executable instructions for the processor to perform any of examples 21-34, using the transceiver.

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

[0181] 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.

[0182] 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 media-streaming 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.

[0183] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may 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 toperform 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.

[0184] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0185] 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 may be executed by one or more general-purpose processors or one or more specialpurpose processors.

Claims

What is claimed is:

1. A method for managing a wireless connection with an access network, the method implemented in a user equipment (UE) and comprising: communicating with the access network over the wireless connection, in a first state of a protocol for controlling the wireless connection; receiving, from the access network, a request to release the wireless connection; and transitioning to a second state of the protocol upon the receiving of the request, including refraining from transmitting, to the access network, a UL acknowledgement message acknowledging the request to release the wireless connection.

2. The method of claim 1, wherein the transitioning to the second state of the protocol occurs immediately upon the receiving of the request.

3. The method of claim 1, wherein the transitioning to the second state of the protocol immediately after the transmitting of the acknowledgement message includes: refraining from awaiting, from the access network, a downlink (DL) acknowledgment message acknowledging the UL acknowledgement message.

4. The method of any of the preceding claims, wherein the UL acknowledgement message is one of a Hybrid Automatic Repeat request (HARQ) message or a Radio Link Control (RLC) message.

5. The method of any of the preceding claims, further comprising: transmitting, from the RLC layer to an RLC layer, an indication that the UL acknowledgement message has been transmitted.

6. The method of any of claims 1-4, further comprising: transmitting, from the PHY layer to an RRC layer, an indication that the UL acknowledgement message has been transmitted.

7. The method of 1, wherein the transitioning to the second state of the protocol after the delay includes selecting the delay based on a number of HARQ retransmissions.

8. The method of claim 1, wherein the transitioning to the second state of the protocol after the delay includes: selecting the delay based on whether the request to release the wireless connection was received from a terrestrial or non-terrestrial node of the access network.

9. The method of claim 1, wherein the transitioning to the second state of the protocol after the delay includes: selecting the delay based on a type of a satellite from which the request to release the wireless connection was received.

10. The method of claim 9, wherein the selecting of the delay includes: selecting a first duration of the delay in response to determining that the satellite is of a first type; and selecting a second duration of the delay in response to determining that the satellite is of a second type.

11. The method of claim 9, wherein the selecting of the delay includes: selecting a first duration of the delay in response to determining that the satellite is a Geostationary Earth Orbit (GEO) satellite; selecting a second duration of the delay in response to determining that the satellite is a Medium-Earth Orbit (MEO) satellite; and selecting a third duration of the delay in response to determining that the satellite is a Low-Earth Orbit (LEO) satellite (LEO) satellite.

12. The method of any of the preceding claims, wherein: the second state of the protocol is an RRC INACTIVE state or an RRC IDLE state.

13. The method of any of the preceding claims, further comprising: storing a UE access stratum (AS) context in response to the request to release the wireless connection.

14. The method of claim 13, wherein the UE AS context includes one or more of security key or a measurement configuration.

15. A user equipment (UE) comprising: a transceiver; and processing hardware configured to implement according to any of the preceding claims.

Images