Managing communications and out-of-coverage scenarios in non-terrestrial networks

Abstract

A UE (102) and a RAN node (104) communicating via the NTN operate to avoid wasting radio communication resources and battery power of the UE during off-coverage of the NTN. Upon determining (908) that the UE is outside of NTN coverage, the UE avoids (910) seeking a reconnection until determining that the UE is in NTN coverage. Upon detecting an upcoming out-of-coverage period, the RAN node sends an RRC release message to the UE. The RRC release message may include a timer value that exceeds an estimated duration of upcoming out of coverage, and the UE waits for a time interval corresponding to the timer value before attempting to reconnect.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communication systems, and in particular to communications involving non-terrestrial network (NTN) elements such as satellites. Background Art

[0002] This background description is provided for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors (to the extent that it is described in this background section) and aspects of the specification that otherwise may not be considered prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0003] In general, a base station operating a cellular radio access network (RAN) uses a certain radio access technology (RAT) and multiple layers of a protocol stack to communicate with a user equipment (UE). For example, the physical layer (PHY) of the RAT provides a transport channel to the medium access control (MAC) sublayer, which in turn provides a logical channel 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 arranged above the PDCP sublayer.

[0004] The RRC sublayer specifies: an RRC_IDLE state, in which the UE does not have an active radio connection with a base station and does not store a UE access stratum (AS) context; an RRC_CONNECTED state, in which the UE has an active radio connection with a base station; and RRC_INACTIVE, which allows the UE to transition back to the RRC_CONNECTED state more quickly due to radio access network (RAN) level base station coordination and RAN paging procedures. Depending on different implementations or scenarios, the base station may configure a small data transmission (SDT) for a UE operating in RRC_INACTIVE to transmit one or more small packets.

[0005] 5G technology mainly relies on traditional (legacy) terrestrial networks. However, the Third Generation Partnership Project (3GPP) organization has proposed to extend 5G communications to non-terrestrial networks (NTNs) using 5G New Radio (NR) technology or using Long Term Evolution (LTE) technology customized for narrowband Internet of Things (NB-IoT) or enhanced machine type communication (eMTC) scenarios. In NTNs, RF transceivers are installed on satellites, unmanned aircraft systems (UAS) (also known as drones, balloons, airplanes), or other suitable devices. For simplicity, the following discussion refers to all such devices as satellites. In addition to satellites, NTNs may also include satellite gateways (sat-gateways) that connect non-terrestrial networks to public data networks, feeder links between satellite gateways and satellites, service links between satellites and UEs, and inter-satellite links (ISLs) when satellites form constellations.

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

[0007] GSO satellites are stationary relative to the surface of the Earth and are able to communicate continuously with the same one or a few satellite gateways within the satellite's target coverage area (e.g., a region or even a continent). Non-GSO satellites change their position relative to the surface of the Earth over time and are therefore only able to communicate temporarily with one or a few serving satellite gateways at different times. NTN is designed to ensure service and feeder link continuity between successive serving satellite gateways while having sufficient duration for mobility anchoring and handover.

[0008] Satellites can support transparent or regenerative (with onboard processing) payloads and typically generate several beams for a given service area defined by the field of view. The coverage area of ​​the beam typically has an elliptical shape and depends on the onboard antenna configuration and elevation angle. For transparent payload implementations, the satellite can apply RF filtering as well as frequency conversion and amplification without changing the waveform signal. For regenerative payload implementations, the satellite can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and compilation / modulation. This approach is actually equivalent to implementing most of the functions of a base station such as a gNB.

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

[0010] Compared with terrestrial network (TN) communication, NTN communication has a very long delay caused by the service link (i.e., the link between the UE and the satellite) and the feeder link (i.e., the link between the satellite and the base station). When a UE in an idle state (e.g., the UE operates in the RRC_IDLE state without a UE AS context) initiates data transmission in the NTN, the UE must perform several processes with the base station and the core network to communicate application data with the application server. These processes may include a service request process, an RRC connection establishment process, a non-access stratum (NAS) authentication process, a NAS security command process, an RRC security command process, an RRC reconfiguration process, etc. Messages are exchanged between the UE and the base station or the core network, which consumes a lot of time. When the base station detects that the data of the UE operating in the RRC_CONNECTED state is inactive, 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 RRC connection (i.e., the UE in RRC_IDLE stores the UE AS context). When the UE has application data to send, the UE may perform an RRC connection recovery procedure (ie, a single RRC procedure) with the base station to recover the suspended active radio connection and transition to the RRC_CONNECTED state. The UE communicates the application data immediately after completing the RRC connection recovery procedure.

[0011] When a UE in an RRC_INACTIVE state or an RRC_IDLE state with a suspended radio connection initiates an RRC connection recovery 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 recovery procedure with the base station, the UE stops the timer. However, if the timer expires before the UE completes the RRC connection recovery procedure, the UE releases the UE AS context and transitions to RRC_IDLE. In the NTN, when a satellite moves on a specific orbit, such as in the case of an NGSO satellite, the satellite beam coverage area may move and cover different parts of a geographical area due to the orbital movement of the satellite. Therefore, due to, for example, a sparse satellite constellation deployment, a UE located in a related geographical area may experience a situation of discontinuous coverage. In such a situation, due to discontinuous coverage, the UE in the NTN may lose coverage for a long period of time (e.g., tens of minutes to hours). In some cases, the UE in the NTN may initiate an RRC connection recovery procedure when the UE is out of coverage due to temporal discontinuous coverage. The RRC connection recovery procedure triggers a cell search. Since the UE is out of coverage due to discontinuous coverage, the UE may not be able to find a suitable cell in the NTN. Therefore, the cell search wastes the battery power of the UE. Moreover, since the UE did not successfully perform the RRC connection recovery procedure, the timer expires. Once the timer expires, the UE releases the UE AS context and transitions to RRC_IDLE, which will cause a long delay in transmitting data when the UE in coverage establishes a connection next time, because the UE must perform several procedures.

[0012] When the UE communicates with the base station via a satellite in the NTN, the UE may detect a radio link failure on the link with the satellite due to being out of coverage caused by discontinuous coverage. According to Section 5.3.7 in the 3GPP specification 38.331 or 36.331, the UE initiates an RRC connection reestablishment procedure to recover from a radio link failure situation. When initiating the RRC connection reestablishment procedure, the UE starts a timer (i.e., T311) with a timer value and performs a cell search to find a suitable cell. If the UE successfully finds a suitable cell, the UE stops the timer. Otherwise, the UE continues to search for a suitable cell. Since the UE is out of coverage due to discontinuous coverage, the UE may not be able to find a suitable cell. Therefore, the cell search wastes the battery power of the UE. Summary of the invention

[0013] UEs and RAN nodes communicating via NTNs operate to avoid wasting radio communication resources and UE power during periods outside NTN coverage. Upon determining that the UE is outside NTN coverage, the UE avoids seeking to reconnect to the NTN until the UE is again in NTN coverage. This UE behavior saves UE battery power. The UE can transition to an idle state until it is determined that it is back in NTN coverage. A RAN node that detects an upcoming out-of-coverage period for a UE connected to a RAN node via an NTN releases radio communication resources reserved for UE-NE communications by sending an RRC release message to the UE. The RRC release message may include a timer value that exceeds the estimated duration of the upcoming out-of-coverage period, and the UE waits for a time interval corresponding to the timer value before attempting to reconnect. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1A is a block diagram of an example wireless communication system in which a user device and a base station perform methods according to various embodiments.

[0016] Figure 1B The centralized unit (CU) and the distributed unit (DU) are Figure 1A Block diagram of an example base station operating in a system.

[0017] Figure 2A yes Figure 1A A block diagram of an example protocol stack according to which a UE communicates with a base station.

[0018] Figure 2B yes Figure 1A A block diagram of an example protocol stack according to which a UE communicates with a CU and a DU.

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

[0020] Figure 3B is a block diagram of an example NTN node with a transparent payload implementation in which a base station is connected to multiple satellites via the same satellite gateway.

[0021] Figure 4A Shown is the supply Figure 3A An exemplary user plane protocol stack for use with an architecture.

[0022] Figure 4B Shown is the supply Figure 3A An exemplary control plane protocol stack for use with the architecture.

[0023] Figure 5 An example scenario is shown where the UE has satellite coverage during certain time periods separated by intervals of non-coverage.

[0024] Figure 6 This is an example scenario according to which the UE-NE connection is suspended before the UE is out of NTN coverage.

[0025] Fig. 7A , Figure 7B and Figure 7C is an example scenario according to which a radio link failure occurs before the UE is out of NTN coverage.

[0026] Fig. 8A , Figure 8B , Figure 8C and Fig.8D is an example scenario according to which the UE and / or NE detects the upcoming out-of-NTN coverage of the UE.

[0027] Fig.9A , Fig. 9B and Fig. 9C is a flow chart of a UE method in which a UE-NE connection is suspended before being out of NTN coverage according to various embodiments.

[0028] Fig. 10A , Fig. 10B and Fig. 10C is a flow chart of a UE method in which a radio link failure occurs before being outside of NTN coverage according to various embodiments.

[0029] Fig.11 is a flow chart of a UE method in which a UE terminates its attempt to reestablish a connection with an NTN upon detecting that it is out of NTN coverage, according to an embodiment.

[0030] Fig.12 is a flow chart performed by a RAN node connected to a UE via an NTN taking into account an upcoming out-of-NTN coverage according to an embodiment. DETAILED DESCRIPTION

[0031] As discussed in more detail below, a user equipment (UE) and / or a network node of a radio access network (RAN) may use the techniques of this disclosure to manage early data communications and to transition the UE between states of a protocol for controlling radio resources between the UE and the RAN.

[0032] First reference Figure 1A, the 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 may operate in a RAN 105 connected to the core network (CN) 110. For example, the CN 110 may be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160. In another example, the CN 110 may also be implemented as a sixth generation (6G) core.

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

[0034] Among other components, the EPC 111 may include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. In general, the SGW 112 is configured to transmit 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, such as 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 a session management function (SMF) 166. In general, the UPF 162 is configured to transmit 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.

[0035] like Figure 1A As shown, base station 104 supports cell 124, and base station 106 supports cell 126. Note that cell 124 has a shape corresponding to the coverage area of ​​a satellite beam, which, unlike cell 126, can be projected on different areas at different times. Cells 124 and 126 may partially overlap, so that UE 102 can select, reselect one of cells 124 and 126, or switch from one of these cells to the other. In order to exchange messages or information directly, base station 104 and base station 106 may support an X2 or Xn interface. In general, CN 110 may be connected to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0036] As discussed in detail below, the UE 102 and / or the RAN 105 may utilize the techniques of this disclosure when a radio connection between the UE 102 and the RAN 105 is suspended, e.g., when the UE 102 is operating in an inactive or idle state of a protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examples below relate to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol.

[0037] The base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory (CRM) storing instructions, and the one or more general-purpose processors execute these instructions. Additionally or alternatively, the processing hardware 130 may include a dedicated processing unit. Figure 1A , the processing hardware 130 includes a processor 132 to process data to be transmitted in the downlink direction by the base station 104, or data received in the uplink direction by the base station 104. The processing hardware 130 also includes a transceiver 134, which is configured to transmit data in the downlink direction and receive data in the uplink direction. The processing hardware 130 further includes a CRM 136 that stores executable code for the processor 132 to perform the method according to the embodiment described in this section. The base station 106 can include substantially similar components. In particular, the components 140, 142, 144, and 146 of the base station 106 can be similar to the components 130, 132, 134, and 136, respectively.

[0038] UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors such as a CPU, and non-transitory computer-readable memory storing machine-readable instructions that can be executed on one or more general-purpose processors, and / or a dedicated processing unit. In an example implementation, the processing hardware 150 includes a processor 152 to process data to be transmitted by UE 102 in an uplink direction, or to process data received by UE 102 in a downlink direction. The processing hardware 150 may also include a transceiver 156, which is configured to transmit data in a downlink direction and receive data in an uplink direction.

[0039] Figure 1B An example distributed or decomposed implementation of any one or more of the base stations 104, 106 is depicted. In this implementation, the base stations 104, 106 include a central unit (CU) 172 and one or more distributed units (DU) 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 processors, and / or a dedicated processing unit. For example, the CU 172 may include a PDCP controller, an RRC controller, and / or an RRC inactive controller. In some implementations, the CU 172 may include a radio link control (RLC) controller configured to manage or control one or more RLC operations or processes. In further implementations, the CU 172 does not include an RLC controller.

[0040] Each DU in DU 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors, and / or dedicated processing units. For example, the processing hardware may include: a MAC controller configured to manage or control one or more MAC operations or processes (e.g., random access processes); and / or an RLC controller configured to manage or control one or more RLC operations or processes. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or processes.

[0041] In some embodiments, the RAN 105 supports integrated access and backhaul (IAB) functionality. In some implementations, the DU 174 operates as an IAB node and the CU 172 operates as an IAB donor. In some embodiments, the RAN 105 supports non-terrestrial network (NTN) functionality.

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

[0043] CU-CP 172A may be connected to multiple CU-UPs 172B via an E1 interface. CU-CP 172A selects an appropriate CU-UP 172B for the requested service of UE 102. In some implementations, a single CU-UP 172B may be connected to multiple CU-CPs 172A via an E1 interface. CU-CP 172A may be connected to one or more DUs 174 via an F1-C interface. CU-UP 172B may be connected to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 may be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such implementations, connectivity between CU-UP 172B and DU 174 is established by CU-CP 172A using a bearer context management function.

[0044] Figure 2A An example protocol stack 200 is shown in a simplified manner according to which a UE 102 may communicate with an eNB / ng-eNB 201 or a gNB 202 (e.g., one or more of base stations 104, 106).

[0045] In the example stack 200, the physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the 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 may in turn provide data transfer services to the Service Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer ( Figure 2A(not shown) provides data transmission services. In some implementations, such as Figure 2A As shown, UE 102 supports both EUTRA and NR stacks to support switching between EUTRA and NR base stations and / or support DC through EUTRA and NR interfaces. Figure 2A As shown, the UE 102 can support the layering of NR PDCP 210 above the EUTRA RLC 206A, and the layering of SDAP sublayer 212 above the NR PDCP sublayer 210.

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

[0047] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide a signaling radio bearer (SRB) or an RRC sublayer ( Figure 2A The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide data radio bearers (DRBs) to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0048] Figure 2B An example protocol stack 250 is shown in a simplified manner in which 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 divided, such as Figure 2B 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support the connection with the 5GC, the NR PDCP 210 provides SRBs to the RRC 214, and the NR PDCP 210 provides DRBs to the SDAP 212 and provides SRBs to the RRC 214.

[0049] Figure 3A A certain type of NTN deployment, referred to as a transparent payload architecture, is shown, which involves a satellite gateway 302 and a "transparent" satellite 304 for extending the range of the Uu interface. In one implementation, the satellite 304 implements frequency conversion and radio frequency (RF) amplifiers in both the uplink direction and the downlink direction. That is, the satellite functions similarly to the functions of an analog RF repeater. Therefore, the satellite 304 relays 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 Uu, and the NTN gateway 302 supports all functions necessary to forward the signals of the Uu interface. The NTN gateway 302 can be placed at the same site as the base station (e.g., eNB, gNB) 104, or connected to the base station 104 at a certain distance via a wired link. More than one NTN gateway can also be connected to the base station. Different transparent satellites can be connected to the same base station on the ground via the same NTN gateway or via different NTN gateways. Figure 3B A situation is shown where two different satellites (304 and 306) are connected to the same base station 104 via the same NTN gateway 302 and the two satellites (304 and 306) cover the earth's surface using two different physical cell IDs (PCIs).

[0050] The NTN user plane protocol stack UPPS involving UE 102, satellite 304, NTN gateway 302, NR base station (i.e. gNB) 104 and UPF 162 is Figure 4A 406. The diagram of NTN UPPS is similar to that of the terrestrial network TN, with the addition of two new nodes, namely the satellite 304 and the NTN gateway 302, placed in the middle of the NR-Uu interface. UE to gNB / gNB to UE communication employs the physical layer 402, the MAC layer 404 and the radio link control RLC layer 406. Further, UE to gNB / gNB to UE communication employs the packet data convergence protocol PDCP 408 and the service data adaptation protocol SDAP 410. gNB to UPF / UPF to gNB communication employs the L1 layer 401 (i.e., the 5G physical layer), the L2 layer 402 (i.e., the 5G data link layer) and the Internet protocol IP 405. Further, gNB to UPF / UPF to gNB communication employs the user datagram protocol UDP 407 and the GPRS tunneling protocol GTP-U 409 for carrying user data (here the acronym GPRS stands for General Packet Radio Service).

[0051] Figure 4B The NTN control plane protocol stack CPPS shown in FIG is also similar to the TN protocol stack. Figure 4A UPPS and Figure 4B Unlike SDAP 410 in UPPS, CPPS includes RRC layer 411. Further, UDP 407 and NGAP 409 are replaced by Stream Control Transmission Protocol SCTP 413 and Next Generation Application Protocol NGAP 414. Descriptions of these protocols and communication layers can be found in the 3GPP technical specifications of the same period.

[0052] In terms of satellite mobility patterns, there are three types of service links supported in NTN:

[0053] Geofixed: configured by a beam that always continuously covers the same geographical area (e.g. in the case of GEO / GSO satellites)

[0054] Quasi-geo-fixed: configured by a beam that covers one geographic area during a limited period of time and a different geographic area during another period of time (e.g., the case of LEO / MEO satellites that can use steerable beams)

[0055] • Geomobile: A beam configuration whereby its coverage area slides over the surface of the Earth (eg, the case of LEO / MEO satellites using fixed or unsteerable beams).

[0056] Using LEO / MEO satellites, eNB can provide quasi-Earth fixed cell coverage or Earth mobile cell coverage. Using GEO satellites, eNB can provide Earth fixed cell coverage.

[0057] although Figure 3A / Figure 3B The transparent payload architecture shown is the focus of current 3GPP development, but the regenerative payload architecture that installs the eNB function on the satellite is also a possible NTN deployment in the future. In this type of architecture, Uu only exists between the satellite and the UE. In general, the technology of this disclosure can be applied to the transparent payload architecture as well as the regenerative payload architecture.

[0058] Figure 5 An example scenario 500 is shown in which a UE 102 located in a geographic area of ​​interest may experience discontinuous coverage due to, for example, a sparse satellite constellation deployment. In the scenario, the UE 102 is served by a LEO satellite 304 from t1 to t2 and by another LEO satellite 306 from t3 to t4. During the period between t2 and t3, the UE 102 is not served by any satellite or any ground base station and is therefore out of coverage. Typically, when a UE loses coverage of a serving cell, the UE begins searching for other cells and then camps on a suitable cell. However, in the case of a UE 102 that loses coverage of a serving cell, the UE 102 may be out of coverage. Figure 5In the example shown, even if UE 102 starts searching for other cells immediately after t2, UE 102 cannot find a cell. The cell search lasts for a long time because the time period between t2 and t3 can vary from tens of minutes to several hours. Therefore, the cell search causes additional, unnecessary power consumption in UE 102. Figure 5 In order to reduce power consumption at the UE in a specific NTN scenario such as the scenario depicted in , the UE may not need to perform a cell search and the access stratum (AS) function may be deactivated during the period when the UE is not within the coverage area of ​​the satellite. In some implementations, the UE knows when the UE will be outside the coverage area and when the UE will be within the coverage area again, so as to reactivate its cell search or AS function just before the UE falls into the coverage of another NTN cell. For example, the ephemeris information broadcasted in the system information provides constellation and trajectory / mobility information of the serving satellite and neighboring satellites, which helps the UE predict / estimate when it will be within the NTN coverage and when it will be outside the NTN coverage. In addition to the ephemeris information, the UE may also use other information to more accurately estimate / predict the coverage of the NTN cell.

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

[0060] Next, refer to Figure 6 To Figure 8F, the discussion involves Figure 1A Several components of the and several example scenarios related to detecting out of coverage in an inactive or connected state. Figure 6 Similar events to those in FIG. 8F are labeled with similar reference numerals (e.g., Figure 6 Event 604 in is similar to Fig. 7A To event 704 in FIG. 7D, Fig. 8A 8E ), with differences discussed below where appropriate. In addition to the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for message delivery and processing) may be applied to events labeled with similar reference numbers in other figures, and may also be applied to both integrated base stations and distributed base stations.

[0061] First reference Figure 6, an example scenario 600 in which the base station 104 includes a CU 172, a DU 174, a satellite 304, and a satellite 306, and a radio connection between the UE 102 and the base station 104 is suspended. In this scenario, the UE 102 initially operates in a connected state 602 and communicates 604 with the DU 174 via the satellite 304, e.g., by using a DU configuration, and communicates 604 with the CU-CP 172A and / or CU-UP 172B via the DU 174 and the satellite 304, e.g., by using a CU configuration.

[0062] In some implementations, the DU configuration includes configuration parameters related to the operation of the RLC, MAC, and / or PHY protocol layers (e.g., RLC 206B, MAC204B, and / or PHY 202B), which are used by the UE 102 and the DU 174 to communicate with each other when the UE 102 operates in a connected state. In some implementations, the DU configuration can be a CellGroupConfig IE or include configuration parameters in a CellGroupConfig IE. The CellGroupConfig IE is defined in 3GPP specification 38.331. In other implementations, the DU configuration can include configuration parameters in RadioResourceConfigDedicated-NB-r13 or RadioResourceConfigDedicated IE defined in 3GPP specification 36.331.

[0063] In some implementations, the CU configuration includes configuration parameters, such as PDCP configuration parameters, radio bearer configuration (e.g., SRB and / or DRB configuration, and / or measurement configuration). In one implementation, the CU configuration includes the RadioBearerConfig IE and / or MeasConfig IE 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, DRB-ToAddMod IE, and / or MeasConfig IE in RadioResourceConfigDedicated-NB-r13 or RadioResourceConfigDedicated IE.

[0064] When the UE 102 is communicating with the base station 104, the CU-CP 172A may determine 614 to transition the UE 102 to suspend the radio connection between the UE 102 and the base station 104 based on data inactivity of the UE 102 (i.e., the UE 102 in the connected state does not have data activity with the base station 104). In some implementations, the base station 104 transitions the UE 102 to an inactive state (e.g., an RRC_INACTIVE state, or an RRC_IDLE state storing a UE AS context) to suspend the radio connection. In some implementations, when the UE 102 is communicating with the base station 104, the UE 102 determines or detects data inactivity, and transmits 606 UE assistance information (e.g., a UEAssistanceInformation message) to the DU 174, the UE assistance information indicating that the UE 102 prefers or requests to transition to the inactive state. Then, the DU 174 transmits 608 a UL RRC message transmission message including the UE assistance information to the CU-CP 172A. Thus, CU-CP 172A may determine that UE 102 is in data inactivity based on UE assistance information. In other implementations, DU 174 may perform data inactivity monitoring for UE 102. CU-CP 172A may transmit a CU to DU message (e.g., a UE context setup request message or a UE context modification request message) to DU 174 to request or command DU 174 to perform data inactivity monitoring. In the case where DU 174 detects or determines that UE 102 is in data inactivity during monitoring, DU 174 may transmit 610 inactivity notification (e.g., UE inactivity notification message) to CU-CP 172A. Thus, CU-CP 172A may determine that UE 102 is in data inactivity based on the inactivity notification received from DU 174. In yet other implementations, CU-UP 172B may perform data inactivity monitoring for UE 102. CU-CP 172A may transmit a CP to UP message (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP 172B to request or command CU-UP 172B to perform data inactivity monitoring. In the case where CU-UP 172B detects or determines during monitoring that UE 102 is in data inactivity, CU-UP 172B may transmit 612 an inactivity notification (e.g., a bearer context inactivity notification message) to CU-CP 172A. Thus, CU-CP 172A may determine that UE 102 is in data inactivity based on the inactivity notification received from CU-UP 172B. In some implementations, CU-CP 172A may determine that UE 102 is in data inactivity based on UE assistance information, an inactivity notification of event 610, and / or an inactivity notification of event 612.

[0065] After a specific period of data inactivity, CU-CP 172A may determine that CU 172 (i.e., CU-CP 172A and / or CU-UP 172B) or UE 102 did not transmit any data in the downlink direction or uplink direction, respectively, during the specific period. In response to this determination, CU-CP 172A may determine to transition UE 102 to an inactive state.

[0066] In response to or after determining that UE 102 is in data inactivity (for a certain period of time), CU-CP 172A sends 616 a bearer context modification request message to CU-UP 172B to suspend data transmission of UE 102. In response, CU-UP 172B suspends data transmission of UE 102 and sends 618 a bearer context modification response message to CU-CP 172A.

[0067] In response to determining to transition UE 102 to an inactive state, CU-CP 172A may generate an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to transition UE 102 to an inactive state. In some implementations, CU-CP 172A may include a suspend configuration (e.g., SuspendConfig IE) in the RRC release message. Then, CU-CP 172A sends 620 a UE context release command message including an RRC release message to DU 174. Subsequently, DU 174 transmits 622 an RRC release message to UE 102. The RRC release message instructs UE 102 to transition to an inactive state. UE 102 transitions 624 from a connected state to an inactive state upon receiving the RRC release message. UE 102 stores a UE access stratum (AS) context (e.g., a UE inactive AS context) in response to the RRC release message. The UE AS context includes configuration parameters, security keys, and / or measurement configurations 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 of the UE 102 operating in an 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 a periodic RNA timer value after receiving the RRC release message (e.g., in response to the RRC release message). In some implementations, the CU-CP 172A may start a network timer with a timer value, similar to a periodic RNA timer. Typically, the timer value of the network timer is greater 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 may 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., 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 a network timer and stores the UE AS context without a 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 a network timer and stores the UE AS context without a time limit.

[0068] In response to the UE context release command message, DU 174 may send a UE context release complete message to CU-CP 172A. In some implementations, DU 174 releases the UE context of UE 102 in response to the UE context release command message. For example, the UE context includes configuration parameters and / or resources configured by DU 174 for UE 102 to communicate with DU 174. In another example, the UE context includes a transport layer configuration configured by DU 174 for communicating data of UE 102 with CU-UP 172B. The transport layer configuration may include an IP address of CU-UP 172B, a first tunnel ID (TEID) of CU-UP 172B, and a second TEID of DU 174.

[0069] In some alternative implementations, CU-CP 172A may include the RRC release message in a DL RRC messaging message instead of a UE context release command message and transmit the DL RRC messaging message to DU 174. Then, at event 622, DU 174 transmits the RRC release message to UE 102. In such cases, CU-CP 172A still transmits the UE context release command message that does not include the RRC release message to DU 174, as described above.

[0070] In some implementations, DU 174 establishes a connection with the NTN gateway to communicate data of UE 102 in or before event 604. In such implementations, after receiving a UE context release command message, transmitting an RRC release message to UE 102, or receiving an acknowledgment of a PDU transmitted by DU 174 to UE 102 including an RRC release message, DU 174 may perform a connection release procedure with the NTN gateway controlling satellite 304 to release the connection. For example, the PDU is a MAC PDU, and the acknowledgment is a hybrid automatic repeat request (HARQ) acknowledgment. In another example, the PDU is an RLC PDU, and the acknowledgment is an RLC acknowledgment. In other implementations, when DU 174 receives a UE context release command message or transmits an RRC release message, DU 174 performs a connection release procedure after a predetermined time.

[0071] In some scenarios or implementations, the UE 102 in an inactive state performs coverage detection (i.e., detects whether the UE 102 is out of coverage). During coverage detection, for example, because the satellite 304 is relative to Figure 5 The UE 102 moves away, so the UE 102 determines 626 that it is out of coverage. Figure 5t2, and the out-of-coverage continues in a period from t2 to t3. In some implementations, the UE 102 determines whether it is out of coverage by calculating the NTN coverage based on the ephemeris information of the serving cell and the neighboring cells and comparing the NTN coverage with the location where the UE 102 is currently located. In other implementations, the UE 102 determines whether it is out of coverage based on time information about when the serving cell is about to stop serving the area (e.g., the t-Service-r17 value broadcasted in the NTN SIB), and determines whether the UE can detect any cell before the time when the serving cell stops serving the area. When the UE detected in event 626 is out of coverage, the UE 102 in the inactive state avoids or stops 628 initiating the RRC connection recovery process. In some embodiments, the UE 102 can initiate the RRC connection recovery process to transmit data (e.g., control plane data or user plane data) when operating in the inactive state. In another implementation, the UE 102 initiates the RRC connection recovery process in response to the expiration of the periodic RAN notification area (RNA) timer when operating in the inactive state. That is, the UE initiates the RRC connection recovery procedure to perform periodic RNA updates. If the UE 102 in an inactive state has data to send or detects expiration of a periodic RNA timer when the UE is out of coverage, the UE 102 avoids initiating the RRC connection recovery procedure. If the UE 102 in an inactive state has initiated the RRC connection recovery procedure to transmit data or perform periodic RNA updates and determines that the UE is out of coverage, the UE 102 stops (e.g., terminates) the RRC connection recovery procedure.

[0072] In some further implementations, UE 102 may determine whether out of coverage is caused by (e.g., as for Figure 5 As described above, if UE 102 determines that being out of coverage is caused by discontinuous coverage, then at event 628, UE 102 avoids or stops initiating the RRC connection recovery process. Otherwise, if UE 102 determines that being out of coverage is not caused by discontinuous coverage (e.g., temporarily out of coverage due to an obstacle), then UE 102 may initiate the RRC connection recovery process when the UE returns to coverage. In other implementations, UE 102 does not consider whether being out of coverage is caused by discontinuous coverage.

[0073] Later, UE 102 determines 630 that UE 102 is in coverage because satellite 306 has moved to the area where UE is staying. Figure 5At time instant t3, UE 102 is in coverage of satellite 306. In some implementations, UE 102 determines that UE 102 is in coverage based on ephemeris information indicating that satellite 306 moves to the area where UE 102 stays. In some implementations, UE 102 receives a system information block (SIB) including ephemeris information from a base station (e.g., base station 104 or 106) via a satellite (e.g., satellite 304 or another satellite). For example, the SIB is SIB32. In another example, the SIB is SIB19. In other implementations, UE 102 may be pre-configured with ephemeris information during manufacturing. In yet other implementations, UE 102 receives ephemeris information via a WiFi network or a terrestrial network. After determining that UE 102 is in coverage, UE 102 may initiate 632 an RRC connection recovery process. In one implementation, UE 102 may initiate an RRC connection recovery process to transmit data (e.g., control plane data or user plane data). In another implementation, the UE 102 may initiate an RRC connection recovery procedure to perform a periodic RAN update because the periodic RAN update timer expired while the UE was out of coverage.

[0074] In some implementations, if UE 102 determines that the coverage outside determined at event 626 is caused by discontinuous coverage, UE 102 can deactivate the AS function. If UE 102 determines that the coverage outside is not caused by discontinuous coverage, UE 102 does not deactivate the AS function. In other implementations, regardless of whether the coverage outside is caused by discontinuous coverage, UE 102 deactivates the AS function. When it is determined at event 630 that the UE is in coverage, UE 102 can activate the AS function. When UE 102 deactivates the AS function, UE 102 can (continue to) maintain the periodic RNA timer running (if UE 102 is configured to start the periodic RNA timer). That is, the AS function does not include operating or running the periodic RNA timer. When UE 102 deactivates the AS function, UE 102 can (continue to) maintain the UE AS context. That is, the AS function does not include keeping or storing the UE AS context. More generally, in some implementations, the AS function does not include functions related to inactive state operations. If the AS functionality includes functionality associated with inactive state operations, the UE 102 will release the UE AS context and transition to an idle state. This will result in a long delay in transmitting data the next time the UE 102 returns to coverage and attempts to establish a connection, because the UE 102 must perform several processes as described above. In some implementations, the AS functionality includes a cell search function that searches for one or more cells. In some implementations, when the UE is out of coverage caused by discontinuous coverage, the UE 102 can turn off the transceiver or put the transceiver into a sleep mode or low power mode. In some implementations, when the UE is out of coverage caused by discontinuous coverage, the UE 102 can put a cellular modem (e.g., a baseband component such as a baseband processor) into a sleep mode or a low power mode.

[0075] Next reference Fig. 7A , example scenario 700A, where base station 104 includes CU 172, DU 174, satellite 304, and satellite 306, and UE 102 detects a radio link failure on a link with satellite 304 while operating in a connected state with base station 104. The differences between scenarios 700A and 600 are discussed below.

[0076] In this scenario, UE 102 initially operates in connected state 702 and communicates 704 with DU 174 via satellite 304, e.g., by using a DU configuration, and communicates 704 with CU-CP 172A and / or CU-UP 172B via DU 174 and satellite 304, e.g., by using a CU configuration. Events 702 and 704 are similar to events 602 and 604, respectively.

[0077] When the UE 102 is operating in a connected state with the base station 104 via the satellite 304, the UE 102 detects 706 a radio link failure on the link with the satellite 304. To detect the radio link failure, the UE 102 performs radio link monitoring on the link with the satellite 304. Before or after detecting 706 the radio link failure, similar to event 626, the UE 102 determines 726 that the UE is out of coverage. In some implementations, when the UE detects that it is out of coverage in event 726, the UE 102 in the connected state avoids 728 initiating an RRC connection reestablishment procedure. In other implementations, the UE 102 starts a timer (e.g., T311) and / or initiates an RRC connection reestablishment procedure in response to the detection 706. In response to the determination 726, the UE 102 stops 728 the ongoing RRC connection reestablishment procedure and / or stops the timer. In response to determining at event 726 that UE 102 is out of coverage, UE 102 transitions 725 to an idle state (e.g., RRC_IDLE without storing UE AS context). In some implementations, if determination 726 occurs before UE 102 detects a radio link failure, UE 102 may stop or suspend radio link monitoring to avoid detecting a radio link failure or initiating an RRC connection reestablishment procedure. When UE 102 is out of coverage, UE 102 in an idle state avoids 729 initiating an RRC connection establishment procedure. In some implementations, the RRC connection reestablishment procedure and the RRC connection establishment procedure are defined in 3GPP specification 38.331. In other implementations, the RRC connection reestablishment procedure and the RRC connection establishment procedure are defined in 3GPP specification 36.331.

[0078] In some further implementations, UE 102 may determine whether out of coverage is caused by (e.g., as for Figure 5 As described above, if UE 102 determines that being out of coverage is caused by discontinuous coverage, then at event 728, UE 102 avoids or stops (e.g., terminates) initiating the RRC connection reestablishment process. Otherwise, if UE 102 determines that being out of coverage is not caused by discontinuous coverage, UE 102 may initiate the RRC connection reestablishment process when out of coverage. In other implementations, UE 102 does not consider whether being out of coverage is caused by discontinuous coverage.

[0079] Later, similar to event 630, UE 102 determines 730 that UE 102 is in coverage. After determining that UE 102 is in coverage, UE 102 in idle state may initiate 732 an RRC connection establishment procedure. In one implementation, UE 102 may initiate an RRC connection establishment procedure to transmit data (e.g., control plane data or user plane data).

[0080] In some implementations, when UE 102 determines that the coverage determined at event 726 is caused by discontinuous coverage, UE 102 can deactivate the AS function. If UE 102 determines that the coverage is not caused by discontinuous coverage, UE 102 does not deactivate the AS function. In other implementations, regardless of whether the coverage is caused by discontinuous coverage, UE 102 deactivates the AS function. When it is determined at event 730 that UE 102 is in coverage, UE 102 can activate the AS function. In some implementations, the AS function includes a cell search function that searches for one or more cells. In some implementations, when UE is outside the coverage caused by discontinuous coverage, UE 102 can turn off the transceiver or put the transceiver into sleep mode or low power mode. In some implementations, when UE 102 is outside the coverage caused by discontinuous coverage, UE 102 can put a cellular modem (e.g., a baseband component such as a baseband processor) into sleep mode or low power mode.

[0081] After UE 102 encounters a radio link failure, UE 102 and DU 174 no longer communicate data via satellite 304 because the link between UE 102 and base station 104 is disconnected. Therefore, DU 174 can detect the data inactivity of UE 102 and transmit 710 an inactivity notification to CU-CP 172A similar to event 610. After UE 102 encounters a radio link failure, UE 102 and CU-UP 172B no longer communicate data via satellite 304 and DU 174 because the link between UE 102 and base station 104 is disconnected. Therefore, CU-UP 172B can detect the data inactivity of UE 102 and transmit 712 an inactivity notification message to CU-CP 172A similar to event 612. After receiving the data inactivity notification message from DU 174 or CU-UP 172B, similar to event 614, CU-CP 172A determines 714 to transition UE 102 to suspend the radio connection with UE 102 based on the UE's data inactivity. In response to this determination, similar to events 616, 618, CU-CP 172A can perform 716, 718 a bearer context modification process with CU-UP 172B. In response to this determination, similar to event 620, CU-CP 172A can transmit 720 a UE context release command message to DU 174 to command DU 174 to release the UE context of UE 102.

[0082] In some implementations, as described for event 620, CU-CP 172A may include an RRC release message in a UE context release command message, or transmit a DL RRC messaging message including an RRC release message to DU 174. Due to the radio link failure, DU 174 is unable to transmit an RRC release message to UE 102. In some implementations, DU 174 transmits an RRC delivery status to CU-CP 172A to indicate that DU 174 failed to transmit an RRC release message. In response to the indication, CU-CP 172A transmits 736 a bearer context release command message to CU-UP 172B instead of a bearer context modification request message to release the UE context of UE 102 at CU-UP 172B. The UE context at CU-UP 172B includes configuration parameters and / or resources configured by CU-UP 172B for UE 102. In another example, the UE context includes a transport layer configuration that the CU-UP 172B configures to communicate data of the UE 102 with the DU 174 and the core network (e.g., SGW 112 or UPF 162). The transport layer configuration may include an IP address of the DU 174, an IP address of the core network, a first tunnel ID (TEID) of the CU-UP 172B, a second TEID of the DU 174, and a third TEID of the core network. In response to the bearer context release command message, the CU-UP 172B transmits 738 a bearer context release complete message to the CU-CP 172A.

[0083] Alternatively, after receiving the data inactivity notification message from DU 174 or CU-UP 172B, CU-CP 172A determines 714 to transition UE 102 to an idle state (e.g., RRC_IDLE without storing UE AS context) based on the UE's data inactivity. In response to the indication, at event 736, CU-CP 172A transmits a bearer context release command message to CU-UP 172B instead of a bearer context modification request message to release the UE context of UE 102 at CU-UP 172B. In response to the bearer context release command message, at event 738, CU-UP 172B transmits a bearer context release complete message to CU-CP 172A.

[0084] Next reference Figure 7B , scenario 700B is substantially similar to scenario 700A. The differences between scenarios 700B and 700A are discussed below.

[0085] DU 174 detects 708 a radio link failure on a link between UE 102 and satellite 304. In some implementations, DU 174 detects the radio link failure because DU 174 has not received PDUs and / or control signals from UE 102 via satellite 304 for a period of time. In response to detecting the radio link failure at event 708, DU 174 transmits 710 an inactivity notification message to CU-CP 172A, even though DU 174 has not yet detected data inactivity from UE 102. Fig. 7A As described above, the inactivity notification message triggers the CU-CP 172A to determine that the UE 102 has data inactivity.

[0086] Next reference Figure 7C , scenario 700C is substantially similar to scenarios 700A and 700B. The differences between scenario 700C and scenarios 700A and 700B are discussed below.

[0087] In response to detecting a radio link failure at event 708, DU 174 transmits 709 a UE context release request message to CU-CP 172A. Fig. 7A As described, after the UE context release request message (e.g., in response to the message), the CU-CP 172A and the CU-UP 172B perform 736, 738 UE context release procedures. Similar to event 720, in response to the UE context release request message, the CU-CP 172A transmits 721 a UE context release command message to the DU 174, except that the CU-CP 172A may not include the RRC release message in the UE context release command message. In this scenario, the CU-CP 172A may not transmit an RRC release message to the UE 102. In this scenario, the CU-CP 172A does not perform 716, 718 bearer context modification procedures with the CU-UP 172B. In some implementations, the CU-CP 172A determines not to transmit an RRC release message to the UE 102, or does not include an RRC release message in the UE context release command message, based on or in response to the UE context release request message.

[0088] In some implementations, DU 174 may include a cause value indicating a radio link failure in the UE context release request message. Thus, CU-CP 172A determines based on the cause value that a radio link failure has occurred on the link between UE 102 and DU 174. In some implementations, CU-CP 172A determines not to transmit an RRC release message to UE 102 or not to include an RRC release message in the UE context release command message based on the cause value.

[0089] Next reference Fig. 8A, scenario 800A is substantially similar to scenario 600. The differences between scenario 800A and scenario 600 are discussed below.

[0090] While the UE 102 is operating in a connected state with the base station 104 via the satellite 304, the UE 102 detects (e.g., determines) 805 that the satellite 304 is moving away from the UE 102, or that the UE 102 will soon be outside the NTN coverage. In response to the detection, the UE 102 may transmit 806 a UE assistance information message to the DU 174, which in turn transmits 808 a UL RRC messaging message including the UE assistance information message to the CU-CP 172A.

[0091] In some implementations, the UE 102 may indicate in a UE assistance information message that the satellite 304 is moving away from the UE 102, or that the UE 102 will soon be outside the NTN coverage. In one implementation, the UE 102 indicates in the UE assistance information message that the distance between the UE 102 and the satellite 304 is above a threshold. In one implementation, the UE 102 determines the threshold by itself. In another implementation, the threshold is preconfigured in the UE 102. In yet another implementation, the threshold is defined in the 3GPP specification. In yet another implementation, the UE 102 receives a message including the threshold from the base station 104. The message including the threshold may be a system information block broadcasted by the base station via the satellite 304, or a dedicated message for the UE 102 (e.g., an RRC reconfiguration message). In some implementations, the UE 102 may include the DL signal strength / quality of the satellite 304 in the UE assistance information message.

[0092] In another implementation, the UE 102 determines that the satellite 304 is moving away from the UE 102 based solely on the DL signal strength / quality of the satellite 304. If the DL signal strength / quality is below a threshold, then at event 806, the UE 102 transmits a UE assistance information message. Otherwise, the UE 102 avoids transmitting a UE assistance information message as at event 806. The UE 102 may determine the threshold on its own or according to 3GPP specifications, be pre-configured with the threshold, or receive the threshold in a broadcast message (e.g., SIB) or a dedicated message (e.g., RRC reconfiguration message) from the base station 104 via the satellite 304. In such an implementation, the UE 102 does not indicate or include a distance in the UE assistance information message. The UE 102 may not detect (e.g., track and / or check) the distance between the UE and the satellite 304.

[0093] In other implementations, the UE 102 determines that the satellite 304 is moving away from the UE 102 based on time information about when the serving cell will soon stop serving the area (e.g., the t-Service-r17 value broadcasted in the NTN SIB). In some implementations, based on the fact that the satellite 304 is moving away from the UE 102, and also based on the ephemeris information indicating that there will be no upcoming satellites in the near future, the UE 102 determines that it will soon be out of NTN coverage.

[0094] In some implementations, the UE 102 includes a timestamp of the detection 805 in the UE assistance information message. Based on the time instant or the timestamp and the ephemeris information, the CU 172 determines when the UE 102 is out of coverage. In other implementations, the UE 102 includes a time period (value) in the UE assistance information message, which indicates that the UE 102 is out of coverage after the time period has passed. In one implementation, the UE 102 determines the time period (value) based on the ephemeris information. Based on the time period (value), the CU 172 determines when the UE 102 is out of coverage. In some implementations, when determining when the UE 102 is out of coverage, the CU 172 considers the propagation delay between the UE 102 and the DU 174. For example, after the time period minus the propagation delay has passed, the CU 172 determines that the UE 102 is out of coverage. In other implementations, the UE 102 includes the propagation delay in the time period (value) between the UE 102 and the DU 174 when determining the time period (value). In yet other implementations, the UE 102 includes a timestamp in the UE assistance information message that indicates when the UE 102 is out of coverage. The CU 172 determines when the UE 102 is out of coverage based on the timestamp.

[0095] After receiving the UE assistance information (e.g., in response to receiving the UE assistance information), CU-CP 172A determines to transition UE 102 to suspend the radio connection with UE 102, similar to the description for event 614. Fig. 7A Before the UE 102 shown in the connected state experiences a radio link failure on the link with the satellite 304, the CU-CP 172A can transition the UE 102 to the inactive state based on this determination.

[0096] In some alternative implementations, at events 806, 808, UE 102 may transmit a measurement report message (e.g., a MeasurementReport message) including information included in the UE assistance information to CU-CP 172A instead of transmitting a UE assistance information message. The benefit of using a UE assistance information message is that UE 102 may not support transmitting a measurement report message.

[0097] Events 820, 822, 824, 826, 828, 830, and 832 are Fig. 8A It is collectively referred to as the state transition and coverage detection process 890.

[0098] Next reference Figure 8B , scenario 800B is substantially similar to scenarios 800A and 600, except that CU-CP 172A transitions UE 102 to an idle state instead of an inactive state. CU-CP 172A Figure 8B 172A configures UE 102 to transition to the idle state in the RRC release message in . Figure 8B The RRC release message in does not include the suspension configuration to indicate that the UE 102 transitions to the idle state. Events 829 and 833 are similar to events 728 and 732, and the description of events 728 and 732 can apply to events 829 and 833. In some implementations, the UE 102 indicates its preference to transition to the idle state in the UE assistance information. Alternatively, as for Fig. 8A As described, UE 102 still indicates its preference to transition to the inactive state in the UE Assistance Information message.

[0099] When CU-CP 172A determines to transition UE 102 to the idle state, CU-CP 172A transmits 836 a bearer context release command message to CU-UP 172B, similar to event 736. In response, similar to event 738, CU-CP 172B transmits 838 a bearer context release complete message to CU-CP 172A.

[0100] Events 820, 822, 825, 826, 829, 830, and 833 are Figure 8B It is collectively referred to as the state transition and coverage detection process 891.

[0101] In some alternative implementations, similar to scenario 800D, in response to the UE assistance information message, the CU-CP 172A may transition the UE 102 to an inactive state instead of an idle state.

[0102] Next reference Figure 8C , scenario 800C is generally similar to scenarios 800A, 800B, and 600, except that DU 174 detects (e.g., determines) 807 that satellite 304 is moving away from UE 102 or DU 174, and transmits 810 an inactivity notification message to CU-CP 172A in response to the detection. In this scenario, UE 102 may not transmit a message to CU-CP 172A for Fig. 8A Describes the UE assistance information message.

[0103] In some implementations, by detecting the distance between the DU 174 and the satellite 304, the DU 174 can detect that the satellite 304 is moving away from the UE 102 or the DU 174. If the DU 174 detects that the distance is above a threshold, the DU 174 transmits 810 an inactivity notification message to the CU-CP 172A. In one implementation, the DU 174 determines the threshold itself. In another implementation, the threshold is pre-configured in the DU 174. In yet another implementation, the DU 174 receives the threshold from the CU-CP 172A.

[0104] In another implementation, DU 174 determines that satellite 304 is moving away from UE 102 or DU 174 based solely on the signal strength / quality of the feeder link signal from satellite 304 to DU 174. If the signal strength / quality is below a threshold, then at event 810, DU 174 transmits an inactivity notification message. Otherwise, DU 174 does not transmit an inactivity notification message as at event 806. DU 174 may determine the threshold itself, or be pre-configured with the threshold, or receive the threshold from CU-CP 172A.

[0105] In yet another implementation, the DU 174 determines that the satellite 304 is moving away from the UE 102 or the DU 174 based on the UL signal strength / quality from the UE 102 via the satellite 304. If the signal strength / quality is below a threshold, then at event 810, the DU 174 transmits an inactivity notification message. Otherwise, the DU 174 refrains from transmitting an inactivity notification message as at event 806. The DU 174 may determine the threshold itself, or be pre-configured with the threshold, or receive the threshold from the CU-CP 172A.

[0106] In yet another implementation, the DU 174 determines that the satellite 304 is moving away from the UE 102 or the DU 174 based on channel state information (CSI) received from the UE 102 via the satellite 304. The CSI may include a layer 1 reference signal received power (L1-RSRP) value. If the L1-RSRP value is below a threshold, then at event 810 the DU 174 transmits an inactivity notification message. Otherwise, the DU 174 avoids transmitting an inactivity notification message as at event 810. The DU 174 may determine the threshold itself, or be pre-configured with the threshold, or receive the threshold from the CU-CP 172A.

[0107] Next reference Fig.8D, scenario 800D is generally similar to scenarios 800A, 800B, 800C, and 600, except that DU 174 detects 807 that satellite 304 is moving away from UE 102 or DU 174, and similar to event 709, transmits 809 a UE context release request message to CU-CP 172A in response to the detection instead of an inactivity notification message. In process 890 or 891, CU-CP 172A transmits a UE context release command message to DU 174 after (e.g., in response to) the UE context release request message. Unlike event 709, DU 174 does not include a reason indicating a radio link failure in the UE context release request message. Therefore, CU-CP 172A can transition UE 102 to an inactive state or an idle state after receiving (e.g., in response to) the UE context release request message.

[0108] Next, refer to FIG. 9A to FIG. 12 Several example methods that may be implemented in a UE (e.g., UE 102) or a RAN node (such as a base station (BS), a DU of a BS, or a CU of a BS) are discussed. Each of these methods may be implemented using processing hardware, such as one or more processors, to execute instructions stored on a non-transitory computer-readable medium, such as a computer memory.

[0109] First reference Fig.9A , method 900A may be implemented in a UE (eg, UE 102) and includes determining whether to initiate an RRC connection recovery procedure depending on whether the UE is in coverage or out of coverage.

[0110] Method 900A begins at block 902A, where the UE communicates with a base station (e.g., events 604, 804). At block 904, the UE receives an RRC release message from the base station to suspend a radio connection with the base station (e.g., events 622, 822, 890). At block 906, the UE suspends the radio connection in response to the RRC release message (e.g., events 624, 824, 890). At block 908, the UE determines whether the UE is out of coverage (e.g., events 626, 826, 630, 830, 890). If at block 908, the UE determines that the UE is out of coverage, the process proceeds to block 910. At block 910, the UE avoids or stops initiating an RRC connection recovery procedure (e.g., events 628, 828, 890). Otherwise, if at block 908, the UE determines that the UE is in coverage, the process proceeds to block 912. At block 912, the UE may initiate an RRC connection recovery procedure (eg, events 632, 832, 890).

[0111] Fig. 9Bis a flow chart of an example method 900B that is similar to method 900A, except that method 900B includes block 907 instead of block 908 .

[0112] At block 907, the UE determines whether the UE is out of coverage caused by discontinuous coverage (e.g., events 626, 826, 630, 830, 890). If at block 907, the UE determines that the UE is out of coverage caused by discontinuous coverage, the flow proceeds to block 910. Otherwise, if at block 907, the UE determines that the UE is in coverage or out of coverage not caused by discontinuous coverage, the flow proceeds to block 912.

[0113] Fig. 9C is a flow chart of an example method 900C that is similar to method 900A, except that method 900C includes block 909 instead of block 908 .

[0114] At block 909, the UE determines whether the UE is out of coverage and in NTN mode (e.g., events 626, 826, 630, 830, 890). If at block 909, the UE determines that the UE is out of coverage and in NTN mode, the flow proceeds to block 910. Otherwise, if at block 909, the UE determines that the UE is in coverage or in TN mode, the flow proceeds to block 912. In some scenarios or implementations, a UE in TN mode may be in coverage or out of coverage.

[0115] In some implementations, when the UE operates in NTN mode, the UE performs operations related to the NTN mode. In some implementations, when the UE operates in TN mode, the UE performs operations related to the TN mode. In some implementations, the NTN mode and the TN mode may be the NR NTN mode and the NR TN mode, respectively. In other implementations, the NTN mode and the TN mode may be the LTE NTN mode (e.g., LTE NB-IoT NTN mode) and the LTE TN mode (e.g., LTE NB-IoTTN mode), respectively.

[0116] Reference now Fig. 10A , method 1000A may be implemented in a UE (eg, UE 102) and includes determining whether to initiate an RRC connection reestablishment procedure depending on whether the UE is in coverage or out of coverage.

[0117] Method 1000A begins at block 1002A, where the UE communicates with the RAN in a connected state (e.g., event 704). At block 1004, the UE detects a radio link failure in the connected state (e.g., event 706). At block 1006, the UE determines whether the UE is out of coverage (e.g., events 726, 728). If at block 1006, the UE determines that the UE is out of coverage, the flow proceeds to block 1008. At block 1008, the UE transitions to an idle state in response to detecting the radio link failure (e.g., event 725). Otherwise, if at block 1006, the UE determines that the UE is in coverage, the flow proceeds to block 1010. At block 1010, the UE initiates an RRC connection reestablishment procedure in response to detecting the radio link failure.

[0118] During the RRC connection reestablishment process, the UE transmits an RRC reestablishment request message to the RAN, receives an RRC reestablishment message from the RAN in response to the RRC reestablishment request message, and transmits an RRC reestablishment complete message to the RAN in response to the RRC reestablishment message. If the RAN operates LTE NB-IoT, the RRC reestablishment request message, the RRC reestablishment message, and the RRC reestablishment complete message are RRCConnectionReestabishmentRequest-NB message, RRCConnectionReestabishment-NB message, and RRCConnectionReestabishmentComplete-NB message, respectively. If the RAN operates NR, the RRC reestablishment request message, the RRC reestablishment message, and the RRC reestablishment complete message are RRCReestabishmentRequest message, RRCReestabishment message, and RRCConnectionReestabishmentComplete message, respectively.

[0119] Fig. 10B is a flow chart of an example method 1000B that is similar to method 1000A, except that method 1000B includes block 1005 instead of block 1006 .

[0120] At block 1005, the UE determines whether the UE is out of coverage caused by discontinuous coverage (e.g., events 726, 728). If at block 1005, the UE determines that the UE is out of coverage caused by discontinuous coverage, the flow proceeds to block 1008. Otherwise, if at block 1005, the UE determines that the UE is in coverage or out of coverage not caused by discontinuous coverage, the flow proceeds to block 1010.

[0121] Fig. 10Cis a flow chart of an example method 1000C that is similar to method 1000A, except that method 1000C includes block 1007 instead of block 1006 .

[0122] At block 1007, the UE determines whether the UE is out of coverage and in NTN mode (e.g., events 726, 728). If at block 1007, the UE determines that the UE is out of coverage and in NTN mode, the flow proceeds to block 1008. Otherwise, if at block 1007, the UE determines that the UE is in coverage or in TN mode, the flow proceeds to block 1010.

[0123] against Fig. 9C The examples and implementations described can be applied to Fig. 10C .

[0124] Reference now Fig.11 , method 1100 may be implemented in a UE (eg, UE 102) and includes terminating an RRC connection reestablishment procedure when the UE is out of coverage.

[0125] Method 1100 begins at block 1102, where the UE communicates with the RAN in a connected state (e.g., event 704). At block 1104, the UE detects a radio link failure in the connected state (e.g., event 706). At block 1106, the UE initiates an RRC connection reestablishment procedure in response to the radio link failure. At block 1108, the UE determines that the UE is out of coverage during the RRC connection reestablishment procedure (e.g., event 726). At block 1110, the UE terminates the RRC connection reestablishment procedure in response to the determination and transitions to an idle state (e.g., event 728).

[0126] In some implementations, at block 1108, the UE determines that the UE is out of coverage caused by discontinuous coverage.

[0127] Next reference Fig.12 , method 1200 can be implemented in a RAN node (e.g., base station 104 or CU-CP 172 of base station 104) to configure a periodic RNA timer value.

[0128] Method 1200 begins at block 1202, where a RAN node communicates with a UE over a radio connection via a first satellite (e.g., events 604, 804). In some implementations, the radio connection may include SRBs and DRBs. At block 1204, the RAN node determines to suspend the radio connection with the UE (e.g., events 614, 814). At block 1206, the RAN node obtains a periodic RNA timer value that ensures that the UE is in coverage when the periodic RNA timer of the UE expires. At block 1208, the RAN node transmits an RRC release message including the periodic RNA timer value to the UE via the first satellite to suspend the radio connection (e.g., events 620, 622, 820, 822, 890).

[0129] In some implementations, at block 1206, the RAN node determines a periodic RNA timer value based on the time at which the UE will be in coverage, the periodic RNA timer value being determined based on ephemeris information of a second satellite (e.g., satellite 306) and other information (e.g., a geographic area or GNSS coordinates of the UE). In some implementations, the RAN node is pre-configured with a periodic RNA timer value that is determined offline based on ephemeris information and other information (e.g., a fixed geographic area or fixed geographic coordinates of a stationary UE). In other implementations, if the second satellite (e.g., satellite 306) provides a quasi-earth fixed cell that can cover the entire cell provided by the first satellite, the RAN node determines the periodic RNA timer value based only on the ephemeris information of the second satellite.

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

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

[0132] The user device (e.g., UE 102) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game 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 smart watch, a wireless hotspot, a femtocell or a broadband router. Further, in some cases, the user device can be embedded in an electronic system, such as a head unit (headunit) or an advanced driver assistance system (ADAS) of a vehicle. Further, the user device can be operated as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

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

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

Claims

1. A wireless communication method (900A, 900B, 900C) performed by a user equipment UE configured to communicate with a non-terrestrial network NTN, the method comprising: Determining (907, 908, 909, 626, 726, 826) that the UE is outside the NTN coverage; as well as Avoid (910, 628, 728, 729, 828, 829) seeking to reconnect to the NTN until it is determined that the UE is within the coverage of the NTN. 2 . The wireless communication method according to claim 1 , wherein before determining that the UE is out of coverage of the NTN, the UE connection with the NTN is suspended in response to a radio resource control (RRC) release command.

3. The wireless communication method according to claim 2, wherein the RRC release command includes a timer value, the method further comprising: When the time interval corresponding to the timer value expires, an RRC reconnection procedure is initiated.

4. The wireless communication method according to any one of claims 2 or 3, further comprising: Before determining that the UE is outside the NTN coverage, detecting an upcoming NTN out-of-coverage; as well as In response to the detecting, UE assistance information is transmitted to the NTN. 5 . The wireless communication method of claim 4 , wherein the receiving of the RRC release command occurs after the transmitting of the UE assistance information.

6. The wireless communication method according to any one of claims 2 to 5, wherein the RRC release command includes a timer value, and the method further comprises: After a time interval corresponding to the timer value, a radio resource control RRC reconnection procedure is initiated. 7 . The wireless communication method according to claim 1 , wherein before determining that the UE is out of the NTN coverage, the UE connection is disconnected due to a radio link failure.

8. The wireless communication method according to claim 7, further comprising: When it is determined that the UE is outside the NTN coverage, a radio resource control RRC reconnection process initiated after the radio link failure is terminated.

9. The wireless communication method according to any one of claims 1 to 8, further comprising: When outside the NTN coverage, it transitions to the idle state. 10 . The wireless communication method according to claim 1 , wherein determining that the UE is outside the NTN coverage comprises determining that the outside the NTN coverage is caused by discontinuous coverage. 11 . The wireless communication method according to claim 1 , wherein determining that the UE is outside the NTN coverage is performed when the UE operates in NTN mode.

12. The wireless communication method according to any one of claims 1 to 11, further comprising: After determining that the UE is within the coverage of the NTN, an NTN connection establishment procedure is initiated.

13. A wireless communication method (1200) performed by a radio access network RAN ​​node connected to a user equipment UE via a non-terrestrial network NTN, the method comprising: upon detecting an upcoming NTN out-of-coverage period, during which the RAN node is unable to communicate with the UE via the NTN, determining (1204) to suspend a radio connection with the UE; obtaining (1206) a timer value to be used by the UE to wait before attempting to reconnect to the RAN node, the timer value exceeding the estimated duration of the upcoming out-of-coverage period; as well as A radio resource control (RRC) release message including the timer value is transmitted (1208) to the UE.

14. The wireless communication method according to claim 13, further comprising: The upcoming out-of-coverage period is estimated based on the location of the UE and satellite-related information.

15. A wireless communication device (102, 104), comprising: A transceiver (136, 156), a processor (134, 154), and a computer-readable storage medium (138, 158) storing executable instructions for the processor to perform any of the methods according to claims 1 to 14 using the transceiver.

Images