Accessing a satellite for a feeder-link switchover

Abstract

A user equipment (UE) receives (510), via a service link and from a node of a non-terrestrial radio access network (RAN), assistance information related to a switchover of the node from a first feeder link (FL), via which the node is coupled to a first core network (CN), to a second FL, to connect to a second CN; and determines (741), based on the assistance information, whether to perform a registration update.

Description

ACCESSING A SATELLITE FOR A FEEDER-LINK SWITCHOVERCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 554,827 entitled “Method and System for Handling UE Accessing Regenerative-Based Satellite for Feeder Link Switchover,” filed on February 16, 2024 and provisional U.S. Patent Application No. 63 / 554,893 entitled “Method and System for Providing Feeder Link Switchover Event Information for a UE Accessing Regenerative-Based Satellite,” filed on February 16, 2024. 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 communications and, more particularly, to a user equipment (UE) accessing a non-terrestrial network (NTN) when a feeder link between a terrestrial station and a satellite changes.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] Although the fifth generation (5G) communication technology relies primarily on terrestrial networks, the 3rd Generation Partnership Project (3GPP) organization has proposed to extend 5G communications to non-terrestrial networks (NTNs) with 5G new radio (NR) access techniques or with Long-Term-Evolution (LTE) access techniques. In an NTN, a radio frequency (RF) transceiver can reside on a satellite, an uncrewed aircraft system (UAS) also referred to as a drone, a balloon, an airplane, or another suitable apparatus. For simplicity, the discussion below refers to all such apparatus as satellites.

[0005] In addition to satellites, an NTN can include sat-gateways that connect the NTN to a public data network, feeder links between sat-gateways and satellites, service links to UEs, andinter-satellite links (ISL) when satellites form constellations. A satellite can belong to one of several types based on altitude, orbit, and beam footprint size. The types include a Low-Earth Orbit (LEO) satellite, a Medium-Earth Orbit (MEO) satellite, a Geostationary Earth Orbit (GEO) satellite, a UAS platform (including High Altitude Platform Station, HAPS), and a High Elliptical Orbit (HEO) satellite. GEO satellites are also known as Geosynchronous Orbit (GSO) satellites, and LEO / MEO satellites are also known as non-GSO (NGSO) satellites.

[0006] A GSO satellite can communicate with one or several sat-gateways deployed over a satellite targeted coverage area (e.g. a region or even a continent). A non-GSO satellite at different times can communicate with one serving sat-gateways via one feeder link or with several serving sat-gateways via respective feeder links. One of the objectives of NTN design is service and feeder link continuity between successive serving sat-gateways, with sufficient time duration to proceed with mobility anchoring and handover.

[0007] A satellite can support a transparent payload, to essentially operate as a radio repeater and extend the Uu interface for a terrestrial base station, or a regenerative payload that provides on-board processing to implement base station functionality, e.g., at least a portion of the functionality of a Next Generation Node B (gNB). A satellite typically generates several beams for a given service area bounded by the field of view of the satellite. The footprints of the beams typically have an elliptic shape and depend on the on-board antenna configuration and the elevation angle of the satellite. For a transparent payload implementation, a satellite can apply 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 / or coding / modulation.

[0008] The regenerative-payload approach presents several challenges related to feeder link switchover. In particular, a user equipment (UE) can access, via a service link, a base station mounted on a satellite defining a node of a satellite-based radio access network (RAN-Sat), while remaining substantially stationary relative to the satellite. The satellite can move relative to the terrestrial network elements and, at some point, switch from a feeder link connecting the satellite to a first terrestrial station (or an “earth station” (ES) 1) to a feeder link connecting the satellite to a second terrestrial station, ES2. The switchover results in a change in Transport Network Layer (TNL) association between the RAN-Sat node and the core network (CN),particularly at the Access and Mobility Management Function (AMF) in a 5G core (5GC) or Mobility Management Entity (MME) in an evolved packet core (EPC) in case of the 4G implementation. The UE meanwhile can continue to communicate with the RAN-Sat node via the same service link.

[0009] When the ESI and ES2 belong to different service areas, the serving AMF or MME can change after a feeder link switchover. The UE accordingly should perform a mobility registration update. However, it is unclear how the UE can determine that a feeder link switch event has occurred.

[0010] Further, in contrast to the transparent payload satellite architecture, in the regenerative architecture, the TNL association occurs over the feeder link, and thus a feeder link switchover results in longer delays for transferring RAN-Sat configurations from a previously serving AMF or MME to a target AMF or MME, when a change in the service area requires a change in the AMF or the MME. During the switchover, the UE can remain within the area of coverage of the satellite and maintain the service link. The UE thus can have a service link while there is no feeder link for data transmission, which can result in the UE consuming power inefficiently. It is unclear how the UE should efficiently handle this scenario.

[0011] Still further, because a feeder link switchover affects all UEs in the cell, it is unclear what overload control mechanism(s) might distribute non-access stratum (NAS) signaling for feeder link switchover procedures.SUMMARY

[0012] An example embodiment of the techniques of this disclosure is a method implemented in a UE. The method comprises receiving, via a service link and from a node of a non-terrestrial RAN, assistance information related to a switchover of the node from a first feeder link (FL), via which the node is coupled to a first CN, to a second FL, to connect to a second CN; and determining, based on the assistance information, whether to perform a registration update.

[0013] Another example embodiment of these techniques is a UE comprising a transceiver and processing hardware, where the UE is configured to implement the method above.

[0014] Another example embodiment of these techniques is a method implemented in a node of a first CN of a cellular communication system. The method comprises predicting anupcoming switchover event during which a node of a non-terrestrial RAN performs a switchover, from a first FL that connects the node to the first CN, to a second FL, to connect the node to a second CN; and transmitting, to a UE operating in a cell of the node, assistance information related to performing a registration update due to the FL switchover event.

[0015] Another example embodiment of these techniques is a CN node comprising processing hardware, where the UE is configured to implement the method above.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Fig. l is a block diagram of an example wireless communication system in which a user equipment (UE) and / or a base station efficiently manage feeder link (FL) switchover events;

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

[0018] Figs. 3A and 3B illustrate known regenerative-based satellite access configurations;

[0019] Fig. 4A is a messaging diagram of an example scenario in which a UE receives FL switchover assistance information and uses the switchover assistance information to determine the timing for communicating with the target network;

[0020] Fig. 4B is a messaging diagram of a scenario similar to that of Fig. 4A, but in which the satellite-based radio access network (RAN-Sat) implements, for each affected UE, overload control using a timer with a value selected randomly within a range a core network specifies;

[0021] Fig. 4C is a messaging diagram of a scenario in which the RAN-Sat uses a similar overload control as in the scenario of Fig. 4B, but based on the information the core network provides for the specific UE;

[0022] Fig. 4D is a messaging diagram of a scenario similar to that of Fig. 4A, but in which the UE supports overload control by operating a timer with a value selected randomly within a range the core network provides to the UE;

[0023] Fig. 5A is a messaging diagram of an example scenario in which a UE receives FL switchover assistance information via a broadcast message and uses the switchover assistance information to determine the timing for communicating with the target network;

[0024] Fig. 5B is a messaging diagram of a scenario similar to that of Fig. 5 A, but in which the UE also receives, as a part of the broadcast, timing information for implementing overload control;

[0025] Fig. 5C is a messaging diagram of a scenario in which the UE uses a similar overload control as in the scenario of Fig. 5B, but based on the UE-specific information from the core network;

[0026] Fig. 5D is a messaging diagram of a scenario similar to that of Fig. 5 A, but in which the UE supports overload control by operating a timer with a value selected randomly within a range the core network provides to the UE;

[0027] Fig. 6 is a messaging diagram of a scenario generally similar to those of Figs. 4A-5D;

[0028] Fig. 7 is a flow diagram of an example method for determining whether to perform a registration update in view of FL assistance information, which can be implemented in a UE of Fig. 1; and

[0029] Fig. 8 is a flow diagram of an example method for coordinating the handling of an FL switchover event at a UE, which can be implemented in a CN node of Fig. 1.DETAILED DESCRIPTION OF THE DRAWINGS

[0030] As discussed in more detail below, a network provides FL switchover assistance information to a UE. When the UE detects an upcoming FL switchover event, the UE determines whether a registration update is necessary based on the FL switchover assistance information. In particular, when the UE determines that the FL switchover event involves a core network, the UE can determine that a registration update is necessary. In some cases, the UE further determines the timing of the registration update based on the FL switchover assistance information. In some implementations, the UE receives FL switchover assistance information in a broadcast message in a currently serving cell, and in other implementations the UE receives the FL switchover assistance information message in a message addressed specifically to the UE.

[0031] The UE and / or the network can also implement overload control to prevent a large number of UEs from requesting registration updates at the same time. To this end, the UE and / ora base station can select timer values within a certain range, which the core network can specify, or which can be pre-configured for the FL switchover procedure.

[0032] Referring first to Fig. 1, an example wireless communication system 100 includes a UE 102, a base station 104 operating on a satellite 103 according to the regenerative payload architecture, as a part of a satellite radio access network (RAN-Sat) 105, and core networks (CN) 110A and HOB. Although the RAN 105 in this and the subsequent examples is a RAN-Sat, in general the techniques of this disclosure can apply to any suitable NTN RAN or a non-terrestrial node of a RAN. In general, the RAN-Sat 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 base station 104 connects to the CN 110A via a feeder link 120A and a terrestrial network element 121 A, and to the CN 110B via a feeder link 120B and a terrestrial network element 121B. The feeder links feeder link 120A and 120B can support the Sl-C and SC-U interfaces. The base station 103 can be an Evolved Node B (eNB) or a Next Generation Node B (gNB), for example.

[0033] The CN 110A can be implemented as an evolved packet core (EPC) 111A or a fifth generation (5G) core (5GC) 160A, for example. The CN 110A can also be implemented as a sixth generation (6G) core in another example.

[0034] The EPC 111 A 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.

[0035] The 5GC 160A can include an Access and Mobility Management Function (AMF) 164A, a Policy Control Function (PCF) 160A, a Session Management Function (SMF) 166 A, an Authentication Server Function (AUSF) 174A, and a Unified Data Management Function (UDM) 178A. The AMF 164A is generally configured to manage registration, connection, and mobility of a UE (such as the UE 102) and provide transport for session management (SM) messages between the UE 102 and the SMF 366. The SMF 366 is generally configured to manage packet data unit (PDU) sessions, allocate Internet Protocol (IP) addresses for UEs, andprovide downlink (DL) notifications. The PCF 160A manages policies such as quality of service (QoS) and authentication policies, for example. The UDM 178 A is generally configured to handle user identification, access authorization based on subscription data, and subscription management.

[0036] The CN HOB can include components 11 IB-116B similar to the components 111A- 116A, and 160B-178B similar to the components 160A-178A. In some configurations of the system 100, the CNs 110A and HOB implement different generations of technology, e.g., the CN 110A implements the 5GC 160A functionality, and the CN HOB implements the EPC 11 IB functionality. In other configurations, the CN 110A and the CN HOB implement the same generation of technology.

[0037] The UE 102 is equipped with processing hardware 130 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 UE 102 further includes a transceiver 132 configured to transmit data in the uplink direction and receive data transmitted in the downlink direction. A memory 134 can include an FL switchover controller 136 configured to efficiently detect and manage FL switchover events and manage the related overload, as discussed in further detail below.

[0038] The base station 104 similarly is equipped with processing hardware 140 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 base station 104 further includes a transceiver 142 configured to transmit data in the downlink direction and receive data transmitted in the uplink direction. A memory 144 can include an FL switchover controller 146 configured to generate FL switchover assistance information, manage overload related to FL switchover assistance information, etc.

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

[0040] In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in 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 206 A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0041] 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.”

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

[0043] For clarity, Figs. 3A and 3B illustrates known scenarios associated with regenerativebased satellite access. Referring first to Fig. 3A, a base station 304, which can be implemented as an eNB-Y, operates on a LEO satellite 303. Earth stationary cells 323 cover countries 1, 2, 3 in this scenario, and the UE 102 in this scenario is in a cell of country 2 and accesses the base station 304 via a Uu service link 325. The base station 304 connects, via a feeder link 320, to anearth station (ES) 321, which in turn connects, via a private IP network 380, to three MME pools corresponding to countries 1, 2, and 3, respectively.

[0044] Fig. 3B illustrates a switchover from a feeder link 320A to a feeder link 320B. The LEO satellite 303 moves in the direction of the arrow in Fig. 3B. The UE 102 is substantially stationary in a certain earth stationary cell, while the base station 304 mounted on the LEO satellite 303 moves out of the range of an ES 321A and moves into the range of an ES 321B. According to this configuration, the ES 321 A and the ES 321B access the same MME 314 and SGW 312.

[0045] However, the switchover from the feeder link 320A to the feeder link 320B in some scenarios also necessitates a change in core networks. The UE 102 in this case should transmit a registration request for a mobility registration update procedure.

[0046] Next, several scenarios in which a UE efficiently manages the FL switchover event at a serving NTN base station are discussed with reference to Figs. 4A-5D. Generally speaking, similar events in these fitures are labeled with similar reference numbers that share two least significant digits, with differences discussed below where appropriate. For example, event 430 is similar to event 530, and event 440 is similar to event 540.

[0047] Referring first to a scenario 400A illustrated in Fig. 4A, a node of the RAN-Sat 105, such as the base station 104, performs an FL switchover that requires a change from the source (or “old”) AMF 164A to the target (or “new”) AMF 164B. For convenience, the discussion below refers to a node of the RAN-Sat 105 simply as “the RAN-Sat 105.”

[0048] The S-AMF 164A predicts 402A an upcoming FL switchover event based on such factors as for example local pre-configuration information, ephemeris data from an operations and maintenance (O&M) server, or feeder link switchover event information from the RAN-Sat 105. Before the FL switchover event starts, the S-AMF 164A initiates an FL switchover preparation by sending 410A, to the UE 102, a UE Configuration Update Command message including FL switchover assistance information and / or a configuration update indication. Although Fig. 4A illustrates only one UE 102, in general the S-AMF 164A can notify 410A in this manner every affected UE.

[0049] In one example implementation, the FL switchover assistance information includes a dedicated information element (IE) defined specifically to convey the duration of an FL switchover period and / or the start time of the FL switchover event. This dedicated can be referred as a FL switchover timing assistance IE, for example.

[0050] In another example implementation, the FL switchover assistance information includes a dedicated IE, which can be referred to as an FL switchover indication, defined specifically to indicate an imminent start of the FL switchover event. The UE 102 in this case can use a certain default value as the duration of the FL switchover period. The UE 102 can consider the FL switchover period started immediately upon receiving the FL switchover assistance information, according to this approach.

[0051] In yet another example implementation, both the UE 102 and the S-AMF 164A support the Unavailability Period feature (e.g., as defined in the 3GPP technical specification (TS) 23.501), and the FL switchover assistance information indicates the duration of the unavailability period. The S-AMF 164 A determines the duration of the unavailability period based on the duration of the FL switchover period and / or the start time of the unavailability period.

[0052] Additionally or alternatively to providing the FL switchover assistance information, the S-AMF 164A can include a configuration update indication in the UE Configuration Update Command message. More specifically, if the S-AMF 164A determines 402A that the UE 102 will require a change in the AMF due the change in the service area after the FL switchover event, the S-AMF 164A can include, in the UE Configuration Update Command, the configuration update indication so as to instruct the UE 102 to perform a mobility registration update after completing the FL switchover event is completed. The completion of the FL switchover event can correspond to the end of the FL switchover period duration, for example. When the S-AMF 164A determines that no change of the AMF is necessary after the FL switchover event, the S-AMF does not include a configuration update indication in the UE Configuration Update Command.

[0053] With continued reference to Fig. 4A, the UE 102 sends 412, to the S-AMF 164 A, a UE Configuration Update Completed message. The S-AMF 164A sends 420A, to the RAN-Sat 105, an N2 message, to notify the RAN-Sat 105 of completion of FL switchover preparation for the

[0054] The UE 102 stores 430 the FL switchover assistance information. The UE 102 can apply the switchover assistance information in response to determining that the FL switchover will start imminently. The 102 can transition 431 to the CM-idle state, in which the UE 102 has not active connection to a core network, based on the local configuration or in response to the RAN-Sat 105 disconnecting the RRC, for example. Alternatively, the UE 102 can send a deregistration request to the network, in particular to the S-AMF 164A. The UE 102 starts 432 an FL switchover timer with an expiration period based on (e.g., equal to) the duration of the FL switchover period, so that the FL switchover timer runs during the FL switchover event.

[0055] The S-AMF 164A, the T-AMF 164B, and the RAN-Sat 105 perform 440 an FL switchover procedure or event. During this procedure, the RAN-Sat 105 and the S-AMF 164A release or suspend the N2 connection with the first TNL association, and the RAN-Sat 105 can connect or resume the N2 connection with the second TNL association, with the S-AMF 164A (i.e., the same AMF) or the T-AMF 164B (i.e., a different AMF).

[0056] When the UE 102 determines that the FL switchover event has completed, e.g., based on the expiration of the FL switchover timer, and if the S-AMF 164A did not previously provide 410A a configuration update indication, the UE 102 can send a service request message to the S- AMF 164A, to transition from the CM-idle state to the CM-connected state (not shown). However, if the S-AMF 164A provided 410A a configuration update indication, then, in response to determining that the FL switchover event has completed, the UE 102 sends 442 a registration request message to the T-AMF 164B, prior to sending 470 a service request message in order to resume services. The UE 102 can send the registration request message after the FL switchover timer has expired (and thus the FL switchover period has ended) and, in some of the implementations, after an additional timer with a random timer value based on the local configuration. Further, if the UE 102 deregistered from the S-AMF 164A during the FL switchover event, the UE 102 can send an initial registration request to the T-SMF 164B.

[0057] The T-AMF 164B retrieves 460 a UE context from the S-AFM 164A by sending an Namf Communication UEContextTransfer message and receiving anNamf Communication UEContextTransfer response message in response. The procedure 460 can include additional messaging related to retrieving a UE identify, authentication, AUSF selection, UDM selection, etc. specified in TS 23.502 V18.4.0 (2023-12) Figure 4.2.2.2.2-1,steps 4-19. The T-AMF 164B sends 444, to the UE 102, a Registration Accept message. Finally, the UE 102 initiates 470 a service request procedure (e.g., in accordance with TS 23.501) to reestablish one or more PDU session(s) if the UE 102 transitions from the CM-idle to the CM- connected state. Alternatively, if the UE 102 performed 442 an initial registration, the UE 102 initiates 470 a PDU Session establishment request procedure to request a new service.

[0058] As indicated above, the S-AMF 164A in some cases provides 410A the FL switchover assistance information that indicates the duration of the unavailability period. The S-AMF 164A and the UE 102 in this case can implement certain functionality to enhance the support of the Unavailability Period feature describes in TS 23.501 so as to support a feeder link switchover event. This functionality is briefly summarized next.

[0059] First, the FL switchover event can be the cause of the unavailability period, and the duration of the FL switchover period can account for an N2 interface disconnection or suspension with a first AMF via a first feeder link, and an N2 interface reconnection or resumption with a second AMF via a second feeder link. In general, the first AMF and the second AMF can be the same AMF or different AMFs. Further, if a UE indicates support using the “Unavailability Period Support” value, the UE also supports the procedures that occur before and after the FL switchover event completes. Still further, if both the UE and the network indicate support of an unavailability period due to discontinuous coverage and / or FL unavailability, the AMF determines the related parameters as follows: (i) the AMF sets the duration of the unavailability period based on the duration of the FL switchover period, if known; (ii) the AMF sets the start time of the unavailability period based on the start time of the FL switchover event, if known; and (iii) the AMF sets the Unavailability Type field to a value indicating FL switchover.

[0060] For example, when the Unavailability type indicates FL switchover, and when the AMF provides only the duration of the unavailability period and the start of the unavailability period, the UE determines the FL switchover period duration based on the start time for the FL switchover event.

[0061] As another example, when the AMF provides only the duration of the unavailability period, the UE determines that the FL switchover period begins immediately and has the duration of the indicated duration of the unavailability period.

[0062] As yet another example, when the AMF provides only the start time of the unavailability period for the FL switchover event, the UE determines that the duration of the FL switchover period has a default value based on the UE implementation, and that the FL switchover period begins at the indicated start time for the FL switchover event.

[0063] As another example, when the AMF only sets the Unavailability type to a value indicating FL switchover, the UE determines that the FL switchover period has a default duration (which can be based on the UE implementation), and that the FL switchover period begins immediately.

[0064] Next, several approaches to implementing overload control in scenarios similar to those of Fig. 4A are discussed with reference to Figs. 4B-D. Generally speaking, an AMF can implement overload control to distribute NAS signaling to and from UEs during an FL switchover event.

[0065] Referring to Fig. 4B, a scenario 400B is generally similar to the scenario 400A.However, here the S-AMF 164A sends 403, to the RAN-Sat 105, a non-UE-specific N2 message including a maximum offset time value time offset max for an FL switchover, to account for the change in MMEs due to the change in service areas. Procedure 402B otherwise is similar to the procedure 402A discussed above. Based on the received 403 time offset max value, the RAN- Sat 105 determines 450B, for each affected UE including the UE 102, a respective timer duration as a random value less than time offset max. For example, the RAN-Sat 105 can set a value Toffset uEi for UE1, Toffset_uE2 for UE2, etc., where Toffset_UEi and Toffset_uE2 are less than time offset max, and where Toffset _UEI Toffset_UE2. The RAN-Sat 105 starts 450B the corresponding timer for each UE. When the corresponding timer expires for a certain UE, the RAN-Sat 105 disconnects the RRC connection between that UE and the RAN-Sat 105. Subsequently, each UE transmits 442 a registration request and continues as previously described in FIG. 4A.

[0066] Fig. 4C illustrates a scenario 400C generally similar to the scenario 400A, but here the S-AMF 164 sends 420C, to the RAN-Sat 105, an N2 message that includes a time offset max value for the FL switchover, for the UE 102. Based on the received 420C time offset max value, the RAN-Sat 105 determines 450C, for the UE 102, a timer duration as a random valueless than time offset _max. The RAN-Sat 105 starts 450C the timer for the UE 102 and, when the timer expires, terminates the RRC connection with the UE 102.

[0067] Fig. 4D illustrates a scenario 400D generally similar to the scenario 400A, with the differences discussed next. The S-AMF 164A sends 410D, to the UE 102, a UE Configuration Update Command message that can include the FL switchover assistance information and / or a configuration update indication as discussed with reference to the event 410A, and also includes a time offset jnax value for the FL switchover. The S-AMF 164A can include the time offset max value only if the UE 102 will require a change in the AMF after the FL switchover event.

[0068] The UE 102 determines 451 a timer duration as a random value less than time offset max, if the UE Configuration Update Command message includes the time offset jnax value. The UE 102 then activates 451 a timer with the determined timer value and, upon expiration of the timer, the UE 102 transitions to the CM-idle state by requesting, from the RAN-Sat 105, RRC disconnection or sending, to the S-AMF 164A, a deregistration request message to deregister from the CN 110A.

[0069] Now referring to Figs. 5A-D, the UE 102 in some implementations can receive the FL switchover assistance information in a broadcast message such as a system information block (SIB).

[0070] Referring first to a scenario 500A in Fig. 5 A, the RAN-Sat 105 broadcasts 504A FL switch information, which the RAN-Sat 105 can generate locally based on the ephemeris data or receive from an O&M server. The UE 102 then can detect 505 an upcoming FL switchover event based on the received FL switchover information.

[0071] The FL switchover information can be dependent on the FL switchover location and / or the specific time. For example, the FL switchover information can indicate an FL switchover area range represented by ephemeris information (in accordance with TS 38.331, for example). In this case, the UE 102 can determine the duration of the FL switchover period and / or the start time of the FL switchover event. In another implementation, the FL switchover information specifies the duration of the FL switchover period duration and / or the start time of the FL switchover event.

[0072] The UE 102 sends 515, to the S-AMF 164A, a Registration Request message including a request for guidance with respect the FL switchover event, before the FL switchover event starts. The Registration Request message also includes, in one implementation, a duration of an FL switchover period and / or the start time of the FL switchover event, which the UE 102 determines based on the FL switch information in the broadcast message. In another implementation, the Registration Request message includes a FL switchover indication, to indicate to the S-AMF 164A that FL switchover event is imminent, and that the UE 102 requires guidance related to the FL switchover event. In yet another implementation, the Registration Request message indicates the duration of the unavailability period. The UE 102 can implement this approach similar to the discussion of the Unavailability Period feature above. In particular, the UE can set the duration of the unavailability period, the start time of the unavailability period, and the Unavailability Type field as discussed above in connection with enhancing the support of the Unavailability Period feature.

[0073] In response to receiving 515 the Registration Request message, the S-AMF 164A determines 507 whether a change in the AMF is necessary for the given FL switchover event and, when applicable, generates 507 FL switchover assistance information. Similar to the discussion of Fig. 4A above, the FL switchover assistance information can include a dedicated FL switchover timing assistance IE, a FL switchover indication, or unavailability period information enhanced as discussed above. The S-AMF 164A can generate this information based on the local configuration, the information received the RAN-Sat 105 provides, and / or information from an O&M server.

[0074] Further, and also similar to the scenario of Fig. 4A, the S-AMF 164A can determine that the UE 102 will require a change in the AMF due the change in the service area after the FL switchover event and include, in the UE Configuration Update Command, an indication that the UE 102 is to perform a mobility registration update after completing the FL switchover event is completed. The indication can be a configuration update indication as discussed above or another suitable indicator, e.g., an FL switchover update indication. The S-AMF 164A accordingly can omit this indication in response to determining that no change of the AMF is necessary after the FL switchover event.

[0075] The S-AMF 164A then includes the FL switchover assistance information in a Registration Accept message and transmits 516A, to the RAN-Sat 105, the Registration Accept message within an N2 message. The RAN-Sat 105 in turn transmits 517A the Registration Accept message with the FL switchover assistance information to the UE 102.

[0076] Events 530, 531, 532, 540, 542, 544, 560, and 570 are similar to the events 430, 431, 432, 440, 442, 444, 460, and 470 discussed above. When determining whether to send 542 a registration request message to the T-AMF 164B or send a service request to transition to the CM-connected state, the UE 102 can consider whether UE 102 received 517A a configuration update indication or the FL switchover update indication, for example.

[0077] Next, several approaches to implementing overload control in scenarios similar to those of Fig. 5 A are discussed with reference to Figs. 5B-D. Similar to the approaches of Figs. 4B-D, an AMF can implement overload control to distribute NAS signaling to and from UEs during an FL switchover event.

[0078] Referring to Fig. 5B, a scenario 500B is generally similar to the scenario 500A. However, here the RAN-Sat 505 broadcasts 504B that a SIB that includes not only FL switch information but also a maximum offset time value time offset max for the FL switchover. Based on the time offset max value, the RAN-Sat 105 determines 550B, for each affected UE including the UE 102, a respective timer duration as a random value less than time offset max (similar to the event 450B discussed above). When the corresponding timer expires for a certain UE, the RAN-Sat 105 disconnects the RRC connection between that UE and the RAN-Sat 105. The UE 102 can send 542 a registration request message to the T-AMF 164B switchover timer has expired (and thus the FL switchover period has ended) and, in some of the implementations, after an additional timer with a random timer value less that is less than time offset max. After the timer expires, the UE transmits 542 a registration request and continues as previously described in FIG. 5A.

[0079] Fig. 5C illustrates a scenario 500C generally similar to the scenario 500A. However, here the S-AMF 164A sends 516C, to the RAN-Sat 105, an N2 message including a maximum offset time time offset _max specific to the UE 102. Based on the time offset max value, the RAN-Sat 105 determines 550C, for the UE 102, a timer duration as a random value less than time offset max (similar to the event 450C discussed above). The RAN-Sat 105 starts 550C thetimer for the UE 102 and, when the timer expires, terminates the RRC connection with the UE 102.

[0080] Fig. 5D illustrates a scenario 500D generally similar to the scenario 500A, but in this scenario the S-AMF 164A sends 516D, to the RAN-Sat 105, an N2 message enclosing a Registration Accept message that includes FL switchover assistance information as well as a maximum offset time time offset max, and the RAN-Sat 105 in turn transmits 517D the Registration Accept message to the UE 102. The UE 102 determines 451 a timer duration as a random value less than time offset max, if the UE Configuration Update Command message includes the time offset max value. The UE 102 then activates 551 a timer with a value selected random randomly within the time offset max range and, upon expiration of the timer, the UE 102 transitions to the CM-idle state by requesting, from the RAN-Sat 105, RRC disconnection or sending, to the S-AMF 164A, a deregistration request message to deregister from the CN 110A (similar to the event 451 discussed above). The UE 102 can send 542 the registration request message after the timer with the value selected random randomly within the time offset max range has expired, and after the FL switchover timer has expired (and thus the FL switchover period has ended).

[0081] Now referring to Fig. 6, a scenario 600 is generally similar to each of the scenarios 400A-D and 500A-D discussed above, with the differences or variations discussed below.

[0082] The RAN-Sat 105 provides 604 FL switchover event information to the UE 102 (see, e.g., event 504A or 405B) or to the S-AMF 164A (see, e.g., event 402A or 402B). The S-AMF 164A also can obtain information related to the FL switchover event from an O&M server or a location configuration. The UE 102 (see, e.g., event 505) or the S-AMF 164A (see, e.g., event 402A or 402B) determine or predict 605 whether the FL switchover event is imminent (i.e., will happen in the near future).

[0083] The UE 102 and the S-AMF 164A negotiate 610 FL switchover event parameters or, more generally, FL switchover assistance information (see, e.g., events 410A / 412, 410D / 412, 515 / 516A / 517A, 515 / 516C / 517A, 515 / 516D / 517D). The FL switchover event parameters can include the duration of the FL switchover period and / or the start time of the FL switchover period, as discussed above in connection with FL switchover assistance information. The S-AMF 164A can also determine 610 whether the FL switchover event necessitates a change in the AMFor MME and, in some cases, instructs the UE regarding performing a registration request procedure. The procedure 610 in some cases includes a procedure 616 similar to the procedure 516 discussed above.

[0084] Events 630, 631, 632, 640, 642, 644, 660, and 670 are similar to the events 430 / 530, 431 / 531, 432 / 532, 440 / 540, 442 / 542, 444 / 544, 460 / 560, and 470 / 570 discussed above.

[0085] Fig. 7 illustrates an example method 700, which a UE (e.g., the UE 102) can implement to determine whether and when to send a registration update to the core network. At block 710, the UE receives assistance information related to an FL switchover at the currently serving non-terrestrial RAN node such as a satellite (see, e.g., events 410A, 410D, 504 A, 504B). At block 741, the UE processes the received assistance information to determine whether the FL switchover event requires a registration update.

[0086] Optionally, at block 732, the UE also determines the timing for performing the registration update (see, e.g., events 432 and 532). The timing can correspond to the duration of the FL switchover period. In some cases, to support UE-side overload control, the UE also determines 751 a random timer value within the time offset max range (see, e.g., events 451 and 551), so that the registration update begins after the FL switchover period ends and after the overload control timer with the random timer value expires.

[0087] If, at block 733, the UE determines that a registration update is required, the flow proceeds to block 742, where the UE sends a registration update to the core network (in particular, the target or “new” core network), via the serving non-terrestrial RAN node (see, e.g., events 442 and 542). Then, at block 770, the UE can resume the one or more service(s) by sending a service request message via the non-terrestrial RAN node. When the flow proceeds from block 433 via block 742 to block 770, the service request message travels to the target core network.

[0088] If, at block 733, the UE determines that a registration update is not required, the flow proceeds directly to block 770. The service request message in this case can travel to the source core network.

[0089] Fig. 8 illustrates an example method 800, which a CN node (e.g., the S-AMF 164A) can implement to coordinate or facilitate the handling of an FL switchover event at a UE (e.g.,the UE 102). For convenience, the method 800 is discussed below with reference to an AMF rather than a CN node.

[0090] At block 802, the AMF predicts an upcoming FL switchover event (see, e.g., event 402A, 402B, 507). At block 809, the AMF determines that the upcoming FL switchover event will require a change in the CN, particularly the AMF, for a UE (see, e.g., event 402A, 402B, 507). Next, at block 810, the AMF generates and transmits, to the UE, assistance information related to the FL switchover event (see, e.g., event 410A, 410D, 516A, 516C, 516D). In some implementations, block 810 also includes block 816, at which the AMF also includes a maximum offset time value time offset max for an FL switchover in the message for the UE (see, e.g., event 410D, 516D).

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

[0092] Example 1. A method implemented in a user equipment (UE), the method comprising: receiving, via a service link and from a node of a non-terrestrial radio access network (RAN), assistance information related to a switchover of the node from a first feeder link (FL), via which the node is coupled to a first core network (CN), to a second FL, to connect to a second CN; and determining, based on the assistance information, whether to perform a registration update.

[0093] Example 2. The method of example 1, wherein the assistance information indicates a duration of a switchover event including the switchover.

[0094] Example 3. The method of example 1, wherein the assistance information indicates a start time of a switchover event including the switchover.

[0095] Example 4. The method of any of the preceding examples, wherein the assistance information is included in an information element (IE) dedicated exclusively to conveying FL switchover assistance information.

[0096] Example 5. The method of any of examples 1-3, wherein the assistance information is indicated in an Unavailability Period information.

[0097] Example 6. The method of any of the preceding examples, wherein the assistance information includes an indication that the switchover is to start imminently.

[0098] Example 7. The method of any of the preceding examples, wherein: the determining to perform the registration update is in response to determining that the assistance information includes an indicator instructing the UE to perform the registration update.

[0099] Example s. The method of example 1, wherein: the assistance information is received in a non-access stratum (NAS) message, from the first CN via the RAN.

[0100] Example 9. The method of example 8, wherein the NAS message is a UE Configuration Update Command message.

[0101] Example 10. The method of example 8, wherein the NAS message is a Registration Accept message.

[0102] Example 11. The method of any of examples 1-5 or 8, further comprising: receiving, via a broadcast message and in a cell of the node, an indication related to the switchover event.

[0103] Example 12. The method of example 11, further comprising: sending, to the first CN and in response to the indication related to the switchover event, a request for the assistance information; and receiving, from the first CN and in response to the request, the assistance information.

[0104] Example 13. The method of any of the preceding examples, further comprising: determining, based on the assistance information, when to perform the registration update.

[0105] Example 14. The method of example 13, further comprising: starting an FL switchover timer with a duration determined based on the assistance information; and sending a Registration Request message to the second CN after the FL switchover timer expires.

[0106] Example 15. The method of example 13, further comprising: starting an FL switchover timer with a duration included in a configuration of the UE; and sending a Registration Request message to the second CN after the FL switchover timer expires.

[0107] Example 16. The method of any of examples 1-7, wherein: receiving an indication of a maximum time offset for delaying a performing of the registration update; starting an overload timer with a duration corresponding to a random value that is less than the maximum time offset; and initiating the performing of the registration update after the overload timer expires.

[0108] Example 17. The method of example 16, wherein the maximum time offset is received in a UE Configuration Update Command message, from the first CN.

[0109] Example 18. The method of example 17, wherein the UE Configuration Update Command message further includes the assistance information.

[0110] Example 19. The method of example 16, wherein the maximum time offset is received in a Registration Accept message, from the first CN.

[0111] Example 20. The method of example 19, wherein the Registration Accept message further includes the assistance information.

[0112] Example 21. The method of example 16, wherein the maximum time offset is received via a broadcast message and in a cell of the node.

[0113] Example 22. The method of any of the preceding examples, further comprising: in response to determining to perform the registration update, transitioning to a CM-idle state.

[0114] Example 23. The method of any of the preceding examples, wherein the node of the non-terrestrial RAN is a base station mounted on a satellite, as a regenerative payload.

[0115] Example 24. A user equipment (UE) comprising: a transceiver; and processing hardware configured to implement a method according to any of the preceding examples.

[0116] Example 25. A method implemented in a node of a first core network (CN) of a cellular communication system, the method comprising: determining an upcoming switchover event during which a node of a non-terrestrial radio access network (RAN) performs a switchover, from a first feeder link (FL) that connects the node to the first CN, to a second FL, to connect the node to a second CN; and transmitting, to a UE operating in a cell of the node, assistance information related to performing a registration update due to the FL switchover event.

[0117] Example 26. The method of example 25, wherein: the assistance information indicates at least one of (i) a duration of the switchover event or (ii) a start time of the switchover event.

[0118] Example 27. The method of example 25 or 26, wherein the assistance information is included in an information element (IE) dedicated exclusively to conveying FL switchover assistance information.

[0119] Example 28. The method of example 25 or 26, wherein the assistance information is included in an Unavailability Period information.

[0120] Example 29. The method of any of examples 25-28, wherein the assistance information includes an indication that the switchover event is to start imminently.

[0121] Example 30. The method of any of examples 25-29, wherein: the assistance information is transmitted in a non-access stratum (NAS) message.

[0122] Example 31. The method of any of examples 25-30, wherein: the predicting an upcoming switchover event is based on ephemeris data.

[0123] Example 32. The method of any of examples 25-31, further comprising: in response to predicting that the upcoming switchover event will require the UE to register with the second CN, including, in the assistance information, an indicator instructing the UE to perform the registration update.

[0124] Example 33. The method of any of examples 25-32, further comprising: receiving, from the UE, a request for the assistance information; wherein the transmitting of the assistance information is in response to the request for the assistance information.

[0125] Example 34. The method of any of examples 25-33, further comprising: transmitting, to the UE, an indication of a maximum time offset for delaying a performing of the registration update.

[0126] Example 35. The method of any of examples 25-34, further comprising: transmitting, to the node, a non-UE-specific indication of a maximum time offset for delaying a performing of the registration update.

[0127] Example 36. A node of a core network (CN) comprising processing hardware configured to implement a method according to any of examples 25-35.

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

[0129] Generally speaking, description for one of the above figures can apply to another of the above figures. Any event or block described above can be optional. For example, an event or block with dashed lines 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 usedand can be replaced by “field”, and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters”, and vice versa. The “eNB” can be replaced by “base station”, “gNB”, “6G base station”, “evolved gNB” or 6G gNB.

[0130] 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 intemet-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.

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

[0132] 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 notnecessarily 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).

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

Claims

What is claimed is:

1. A method implemented in a user equipment (UE), the method comprising: receiving, via a service link and from a node of a non-terrestrial radio access network(RAN), assistance information related to a switchover of the node from a first feeder link (FL), via which the node is coupled to a first core network (CN), to a second FL, to connect to a second CN; and determining, based on the assistance information, whether to perform a registration update.

2. The method of claim 1, wherein the assistance information indicates a duration of a switchover event including the switchover.

3. The method of claim 1 or 2, wherein the assistance information indicates a start time of the switchover.

4. The method of any of the preceding claims, wherein: the determining to perform the registration update is in response to determining that the assistance information includes an indicator instructing the UE to perform the registration update.

5. The method of claim 1, wherein: the assistance information is received in a non-access stratum (NAS) message, from the first CN via the RAN.

6. The method of any of claims 1-3 or 5, further comprising: receiving, via a broadcast message and in a cell of the node, an indication related to a switchover event including the switchover.

7. The method of any of the preceding claims, further comprising:determining, based on the assistance information, when to perform the registration update.

8. The method of claim 7, further comprising: starting an FL switchover timer with a duration determined based on the assistance information; and sending a Registration Request message to the second CN after the FL switchover timer expires.

9. The method of any of claims 1-4, wherein: receiving an indication of a maximum time offset for delaying a performing of the registration update; starting an overload timer with a duration corresponding to a random value that is less than the maximum time offset; and initiating the performing of the registration update after the overload timer expires.

10. A method implemented in a node of a first core network (CN) of a cellular communication system, the method comprising: predicting an upcoming switchover event during which a node of a non-terrestrial radio access network (RAN) performs a switchover, from a first feeder link (FL) that connects the node to the first CN, to a second FL, to connect the node to a second CN; and transmitting, to a UE operating in a cell of the node, assistance information related to performing a registration update due to the FL switchover event.

11. The he method of claim 10, wherein: the assistance information indicates at least one of (i) a duration of a switchover event including the switchover or (ii) a start time of the switchover event.

12. The method of claim 10 or 11, further comprising:in response to predicting that the upcoming switchover event will require the UE to register with the second CN, including, in the assistance information, an indicator instructing the UE to perform the registration update.

13. The method of any of claims 10-12, further comprising: transmitting, to the UE, an indication of a maximum time offset for delaying a performing of the registration update.

14. The method of any of claims 10-12, further comprising: transmitting, to the node, a non-UE-specific indication of a maximum time offset for delaying a performing of the registration update.

15. An apparatus comprising processing hardware and configured to implement a method of any of the preceding claims.

Images