Accessing a satellite for feeder link handover

Abstract

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

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to Provisional U.S. Patent Application No. 63 / 554,827, filed February 16, 2024, entitled "Method and System for Handling UE Accessing Regenerative-Based Satellite for Feeder Link Switchover," and Provisional U.S. Patent Application No. 63 / 554,893, filed February 16, 2024, entitled "Method and System for Providing Feeder Link Switchover Event Information for a UE Accessing Regenerative-Based Satellite." The entire contents of these provisional applications are hereby expressly incorporated by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically to user equipment (UE) accessing a non-terrestrial network (NTN) when the feeder link between a ground station and a satellite changes. Background Technology

[0004] This background description is provided for the purpose of generally presenting the context of this disclosure. The work of the currently named inventors (with respect to the work described in this background section) and aspects of the description that may not be otherwise considered prior art at the time of filing are neither expressly nor impliedly acknowledged as prior art to this disclosure.

[0005] Although fifth-generation (5G) communication technology primarily relies on terrestrial networks, the 3rd Generation Partnership Project (3GPP) has proposed extending 5G communication to non-terrestrial networks (NTNs) using either 5G New Radio (NR) access technology or Long Term Evolution (LTE) access technology. In NTNs, radio frequency (RF) transceivers can reside on satellites, unmanned aerial vehicle systems (UAS)—also known as drones, balloons, or aircraft—or other suitable equipment. For simplicity, the following discussion will refer to all such equipment as satellites.

[0006] In addition to satellites, an NTN can also include a satellite gateway connecting the NTN to a public data network, feeder links between the satellite gateway and satellites, service links to the UE, and inter-satellite links (ISLs) when satellites form a constellation. Satellites can belong to several types based on altitude, orbit, and footprint size. These types 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 known as geostationary orbit (GSO) satellites, and LEO / MEO satellites are also known as non-GSO (NGSO) satellites.

[0007] GSO satellites can communicate with one or more satellite gateways deployed over the satellite's target coverage area (e.g., a region or even a continent). Non-GSO satellites can communicate with one serving satellite gateway via a feeder link at different times, or with several serving satellite gateways via corresponding feeder links. One of the goals of NTN design is the continuity of service and feeder links between connected serving satellite gateways, while having sufficient duration for mobility anchoring and handover.

[0008] Satellites can support transparent payloads, essentially operating as radio repeaters and extending the Uu interface of terrestrial base stations, or regenerative payloads that provide onboard processing to enable base station functionality (e.g., at least a portion of the functionality of a next-generation Node B (gNB)). Satellites typically generate several beams for a given service area defined by the satellite's field of view. The coverage area of ​​the beams is typically elliptical in shape and depends on the onboard antenna configuration and the satellite's elevation angle. For transparent payload implementations, satellites can apply RF filtering, as well as frequency conversion and amplification, without altering the waveform signal. For regenerative payload implementations, satellites can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and / or code processing / modulation.

[0009] The regenerated payload approach presents several challenges related to feeder link handover. Specifically, a User Equipment (UE) can access a base station mounted on a satellite via a serving link while remaining substantially stationary relative to the satellite, which defines a node in a satellite-based Radio Access Network (RAN-Sat). The satellite can move relative to terrestrial network elements and, at some point, switch from a feeder link connecting the satellite to a first ground station (or "earth station" (ES) 1) to a feeder link connecting the satellite to a second ground station ES2. This handover results in a change in the 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 the 5G Core (5GC) or at the Mobility Management Entity (MME) in the Evolved Packet Core (EPC) in the case of a 4G implementation. Simultaneously, the UE can continue communicating with the RAN-Sat node via the same serving link.

[0010] When ES1 and ES2 belong to different service areas, the serving AMF or MME can change after a feeder link handover. Therefore, the UE should perform a mobility registration update. However, it is unclear how the UE can determine that a feeder link handover event has occurred.

[0011] Furthermore, compared to the transparent payload satellite architecture, in the regenerative architecture, TNL associations occur on the feeder link. Therefore, when a change in service area requires a change in the AMF or MME, feeder link handover results in a longer delay for transferring the RAN-Sat configuration from the previous serving AMF or MME to the target AMF or MME. During handover, the UE can remain within the satellite's coverage area and maintain the serving link. Thus, the UE can have a serving link but no feeder link for data transmission, which may lead to inefficient power consumption by the UE. It is unclear how the UE should efficiently handle this scenario.

[0012] Furthermore, since feeder link handover affects all UEs in the cell, it is unclear what overload control mechanism can distribute the non-access stratum (NAS) signaling during the feeder link handover process. Summary of the Invention

[0013] An example embodiment of the technology disclosed herein is a method implemented in a UE. The method includes: receiving, via a serving link, auxiliary information from a node in a non-terrestrial RAN relating to the node's switch from a first feeder link (FL) to a second FL to connect to a second CN, the node being coupled to the first CN via the first FL; and determining, based on the auxiliary information, whether to perform a registration update.

[0014] Another example embodiment of these technologies is a UE including a transceiver and processing hardware, wherein the UE is configured to implement the methods described above.

[0015] Another example embodiment of these technologies is a method implemented in a node of a first CN in a cellular communication system. The method includes: predicting an upcoming handover event during which a non-terrestrial RAN node performs a handover from a first FL connecting the node to the first CN to a second FL to connect the node to the second CN; and sending auxiliary information to a UE operating in the cell of that node related to performing a registration update due to the FL handover event.

[0016] Another example embodiment of these technologies is a CN node that includes processing hardware, wherein the UE is configured to implement the methods described above. Attached Figure Description

[0017] Figure 1 This is a block diagram of an example wireless communication system in which user equipment (UE) and / or base station efficiently manage feeder link (FL) handover events; Figure 2 yes Figure 1 A's UE is illustrated in the block diagram of an example protocol stack for communicating with the base station; Figure 3A and Figure 3B Known regeneration-based satellite access configurations are illustrated; Figure 4A This is a message passing diagram of an example scenario in which the UE receives FL handover assistance information and uses the handover assistance information to determine the timing for communicating with the target network; Figure 4B Is with Figure 4A The message passing diagram is similar to that of the scenario, but in which the satellite-based radio access network (RAN-Sat) uses a timer with a value randomly selected within a range specified by the core network to implement overload control for each affected UE; Figure 4C Among them, RAN-Sat is used with Figure 4B A similar overload control scenario, but based on the message passing diagram of a scenario where the core network provides information to a specific UE; Figure 4D Is with Figure 4A The message passing diagram is similar to that of the scenario, but in which the UE supports overload control by operating a timer with a value randomly selected from the range provided to the UE by the core network; Figure 5A This is a message passing diagram of an example scenario in which the UE receives FL handover assistance information via broadcast messages and uses the handover assistance information to determine the timing for communicating with the target network; Figure 5B Is with Figure 5AThe message passing diagram is similar to that of the scenario, but in this scenario, the UE also receives timing information for overload control as part of the broadcast; Figure 5C It is among them that UE uses and Figure 5B A similar overload control scenario, but based on UE-specific information from the core network; Figure 5D Is with Figure 5A The message passing diagram is similar to that of the scenario, but in which the UE supports overload control by operating a timer with a value randomly selected from the range provided to the UE by the core network; Figure 6 Is with Figures 4A to 5D The message passing diagram is largely similar to the scenario. Figure 7 It is possible Figure 1 A flowchart of an example method implemented in the UE for determining whether to perform a registration update based on FL auxiliary information; and Figure 8 It is possible Figure 1 The flowchart shows an example method implemented in the CN node for coordinating the handling of FL handover events at the UE. Detailed Implementation

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

[0019] The UE and / or network can also implement overload control to prevent a large number of UEs from requesting registration updates simultaneously. To this end, the UE and / or base station can select a timer value within a specific range, which the core network can specify or pre-configure for the FL handover process.

[0020] First refer to Figure 1Example wireless communication system 100 includes UE 102, base station 104 operating on satellite 103 according to a regenerative payload architecture—as part of satellite radio access network (RAN-Sat) 105—and core networks (CN) 110A and 110B. Although RAN 105 in this example and subsequent examples is RAN-Sat, in general, the techniques disclosed herein can be applied to any suitable NTN RAN or non-terrestrial node of the RAN. Generally, 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. Base station 104 is connected to CN 110A via feeder link 120A and terrestrial network element 121A, and to CN 110B via feeder link 120B and terrestrial network element 121B. Feeder links 120A and 120B can support S1-C and SC-U interfaces. For example, base station 103 can be an evolved Node B (eNB) or a next-generation Node B (gNB).

[0021] For example, the CN 110A can be implemented as an Evolved Packet Core (EPC) 111A or a 5th Generation (5G) Core (5GC) 160A. In another example, the CN 110A can also be implemented as a 6th Generation (6G) Core.

[0022] EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. Generally, the SGW 112 is configured to deliver 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., Internet networks and / or Internet Protocol (IP) Multimedia Subsystem (IMS) networks).

[0023] 5GC 160A may include Access and Mobility Management Function (AMF) 164A, Policy Control Function (PCF) 160A, Session Management Function (SMF) 166A, Authentication Server Function (AUSF) 174A, and Unified Data Management Function (UDM) 178A. AMF 164A is typically configured to manage the registration, connectivity, and mobility of a UE (such as UE 102) and to provide the transmission of Session Management (SM) messages between UE 102 and SMF 366. SMF 366 is typically configured to manage Packet Data Unit (PDU) sessions, assign Internet Protocol (IP) addresses to UEs, and provide downlink (DL) notifications. For example, PCF 160A manages policies such as Quality of Service (QoS) and authentication policies. UDM 178A is typically configured to handle user identification, access authorization based on subscription data, and subscription management.

[0024] CN 110B may include components 111B-116B similar to components 111A-116A, and components 160B-178B similar to components 160A-178A. In some configurations of system 100, CN 110A and CN 110B implement different generations of technology; for example, CN 110A implements 5GC 160A functionality, and CN 110B implements EPC 111B functionality. In other configurations, CN 110A and CN 110B implement the same generation of technology.

[0025] UE 102 is equipped with processing hardware 130 and / or dedicated processing units, which may include one or more general-purpose processors (such as a CPU) and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors. UE 102 also includes a transceiver 132 configured to transmit data in the uplink direction and receive data transmitted in the downlink direction. Memory 134 may include an FL switching controller 136 configured to efficiently detect and manage FL switching events and manage associated overloads, as discussed in more detail below.

[0026] Base station 104 is similarly equipped with processing hardware 140 and / or dedicated processing units, which may include one or more general-purpose processors (such as a CPU) and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors. Base station 104 also includes a transceiver 142 configured to transmit data in the downlink direction and receive data transmitted in the uplink direction. Memory 144 may include an FL handover controller 146 configured to generate FL handover assistance information, manage overloads associated with the FL handover assistance information, etc.

[0027] Figure 2 An example protocol stack 200 is illustrated in a simplified manner, showing how UE 102 can communicate with eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106).

[0028] In example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRPHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data delivery services to the Serving Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2 (Not shown in A) provides data transfer services. In some implementations, UE 102 supports both EUTRA and NR stacks, such as... Figure 2 As shown in Figure A, this supports handover between EUTRA and NR base stations and / or supports DCs via EUTRA and NR interfaces. Furthermore, as... Figure 2 As shown in Figure A, UE 102 can support the layering of NR PDCP 210 over EUTRA RLC 206A, and the layering of SDAP sublayer 212 over NR PDCP sublayer 210.

[0029] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on PDCP layers 208 or 210) receive packets that can be referred to as Service Data Units (SDUs), and (e.g., to RLC layers 206A or 206B) output packets that can be referred to as Protocol Data Units (PDUs). For simplicity, except where the difference between SDU and PDU is relevant, this disclosure refers to both SDU and PDU as "packets".

[0030] On the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide signaling radio bearer (SRB) or RRC sublayer ( Figure 2(Not shown in A) to exchange, for example, RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0031] For clarity, Figure 3A and Figure 3B Known scenarios associated with regeneration-based satellite access are illustrated. First, refer to... Figure 3A The base station 304, which can be implemented as an eNB-Y, operates on LEO satellite 303. Geostationary cell 323 covers countries 1, 2, and 3 in this scenario, and UE 102 accesses base station 304 in a cell of country 2 via Uu serving link 325. Base station 304 is connected to earth station (ES) 321 via feeder link 320, which in turn connects to three MME pools corresponding to countries 1, 2, and 3 respectively via dedicated IP network 380.

[0032] Figure 3B This illustrates the switching from feeder link 320A to feeder link 320B. LEO satellite 303 in Figure 3B The arrow in the diagram indicates movement in the direction of the movement. UE 102 is essentially stationary in a geostationary cell, while base station 304, installed on LEO satellite 303, moves out of the range of ES 321A and into the range of ES 321B. According to this configuration, ES 321A and ES 321B access the same MME 314 and SGW 312.

[0033] However, in some scenarios, the handover from feeder link 320A to feeder link 320B also necessitates changes to the core network. In this case, UE 102 should send a registration request for the mobility registration update process.

[0034] Next, refer to Figures 4A to 5D This paper discusses several scenarios for UE to efficiently manage FL handover events at the serving NTN base station. Generally, similar events in these figures are labeled with similar figure reference numerals that share two least significant figures, with differences discussed below where appropriate. For example, event 430 is similar to event 530, and event 440 is similar to event 540.

[0035] First refer to Figure 4AIn the scenario 400A shown, a node in RAN-Sat 105—such as base station 104—performs a FL handover that requires a change from the source (or "old") AMF 164A to the target (or "new") AMF 164B. For convenience, the node in RAN-Sat 105 will be referred to as "RAN-Sat 105" in the following discussion.

[0036] The S-AMF 164A predicts an upcoming FL handover event (402A) based on factors such as, for example, local pre-configuration information, ephemeris data from the Operation and Maintenance (O&M) server, or feeder link handover event information from RAN-Sat 105. Before the FL handover event begins, the S-AMF 164A initiates FL handover preparation by sending a UE configuration update command message (410A) to UE 102, including FL handover assistance information and / or configuration update indications. Although... Figure 4A Only one UE102 is illustrated, but in general, the S-AMF 164A can notify the 410A of each affected UE in this way.

[0037] In one example implementation, the FL switching auxiliary information includes a dedicated information element (IE) specifically defined to transmit the duration of the FL switching period and / or the start time of the FL switching event. For example, this dedicated element could be referred to as the FL switching timing auxiliary IE.

[0038] In another example implementation, the FL handover assistance information includes a dedicated IE specifically defined to indicate the imminent start of an FL handover event, which may be referred to as the FL handover indication. In this case, UE 102 can use a default value as the duration of the FL handover period. According to this method, UE 102 can assume that the FL handover period begins immediately upon receiving the FL handover assistance information.

[0039] In another example implementation, both UE 102 and S-AMF 164A support unavailability period characteristics (e.g., as defined in 3GPP Technical Specification (TS) 23.501), and the FL handover assistance information indicates the duration of the unavailability period. S-AMF 164A determines the duration of the unavailability period based on the duration of the FL handover period and / or the start time of the unavailability period.

[0040] As an addition to or alternative to providing FL handover assistance information, S-AMF 164A may include a configuration update indication in the UE configuration update command message. More specifically, if S-AMF 164A determines that UE 102 will require an AMF change due to a change in the service area after the FL handover event, S-AMF 164A may include a configuration update indication in the UE configuration update command to instruct UE 102 to perform a mobility registration update after the FL handover event is completed. For example, the completion of the FL handover event may correspond to the end of the FL handover period duration. When S-AMF 164A determines that an AMF change after the FL handover event is not necessary, S-AMF does not include a configuration update indication in the UE configuration update command.

[0041] Continue to refer to Figure 4A UE 102 sends a 412 UE configuration update complete message to S-AMF 164A. S-AMF 164A sends a 420A N2 message to RAN-Sat 105 to notify RAN-Sat 105 that the FL handover preparation for UE 102 is complete.

[0042] UE 102 stores FL handover assistance information (430). UE 102 can apply the handover assistance information in response to determining that an FL handover is about to begin. For example, UE 102 can transition to a CM-idle state (431) based on local configuration or in response to a RAN-Sat 105 disconnection RRC, in which UE 102 does not have an active connection to the core network. Alternatively, UE 102 can send a deregistration request to the network—specifically to S-AMF 164A. UE 102 initiates an FL handover timer (432) with an expiration period based on (e.g., equal to) the duration of the FL handover period, causing the FL handover timer to run during the FL handover event.

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

[0044] When UE 102 determines that the FL handover event has completed, for example, based on the expiration of the FL handover timer, and if S-AMF 164A did not previously provide a 410A configuration update indication, UE 102 may send a service request message to S-AMF 164A to transition from the CM-idle state to the CM-connected state (not shown). However, if S-AMF 164A provided a 410A configuration update indication, in response to determining that the FL handover event has completed, UE 102 sends a 442 registration request message to T-AMF 164B before sending a 470 service request message to resume service. UE 102 may send the registration request message after the FL handover timer has expired (and therefore the FL handover period has ended), and in some implementations, after an additional timer with a random timer value based on local configuration. Furthermore, if UE 102 is deregistered from S-AMF 164A during the FL handover event, UE 102 may send an initial registration request to T-AMF 164B.

[0045] T-AMF 164B via transmission Namf_Communication_UEContextTransfer Messages and received as responses Namf_Communication_UEContextTransfer Response The message retrieves the UE context from S-AFM 164A (460). Procedure 460 may include additional messaging related to retrieving the UE identifier, authentication, AUSF selection, UDM selection, etc., as specified in step 4-19 of Figure 4.2.2.2.2-1 in TS 23.502 V18.4.0 (2023-12). T-AMF 164B sends a 444 Registration Acceptance message to UE 102. Finally, if UE 102 transitions from CM-idle to CM-connected state, UE 102 initiates a 470 Service Request procedure (e.g., according to TS 23.501) to re-establish one or more PDU sessions. Alternatively, if UE 102 performed a 442 Initial Registration procedure, UE 102 initiates a 470 PDU Session Establishment Request procedure to request new services.

[0046] As indicated above, in some cases, S-AMF 164A provides FL handover assistance information (410A) indicating the duration of unavailability periods. In this case, S-AMF 164A and UE 102 can implement a certain functionality to enhance support for the unavailability period characteristics described in TS 23.501 in order to support feeder link handover events. This functionality is briefly summarized below.

[0047] First, the FL handover event can be the cause of an unavailability period, and the duration of the FL handover period can cover the disconnection or suspension of the N2 interface of the first AMF via the first feeder link, and the reconnection or restoration of the N2 interface of the second AMF via the second feeder link. Generally, the first AMF and the second AMF can be the same AMF or different AMFs. Furthermore, if the UE uses an "Unavailability Period Support" value to indicate support, the UE also supports processes occurring before and after the FL handover event is completed. Moreover, if both the UE and the network indicate support for unavailability periods caused by discontinuous coverage and / or FL unavailability, the AMF determines the relevant parameters as follows: (i) the AMF sets the duration of the unavailability period based on the duration of the FL handover period (if known); (ii) the AMF sets the start time of the unavailability period based on the start time of the FL handover event (if known); and (iii) the AMF sets the unavailability type field to a value indicating FL handover.

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

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

[0050] As another example, when the AMF only provides the start time of the unavailability period of the FL handover event, the UE determines the duration of the FL handover period based on the UE implementation method, which has a default value, and determines that the FL handover period begins at the start time indicated by the FL handover event.

[0051] As another example, when the AMF only sets the unavailability type to a value indicating FL handover, the UE determines that the FL handover period has a default duration (which may be based on the UE implementation) and determines that the FL handover period starts immediately.

[0052] Next, refer to Figures 4B to 4D Discussion in Figure 4A Several methods for implementing overload control in scenarios similar to the one described above. Generally, the AMF can implement overload control to distribute NAS signaling to and from the UE during FL handover events.

[0053] refer to Figure 4BScenario 400B is largely similar to Scenario 400A. However, here, S-AMF 164A sends 403, including the maximum offset time value for FL handover, to RAN-Sat105. time_offset_max Non-UE-specific N2 messages are sent to address changes in the MME due to changes in the service area. Procedure 402B is similar to procedure 402A discussed above in other respects. Based on the received 403 time_offset_max The RAN-Sat 105, for each affected UE including UE 102, determines the corresponding timer duration to be less than 450B. time_offset_max A random value. For example, RAN-Sat 105 can set the value T for UE1. offset_UE1 Set value T for UE2 offset_UE2 etc., of which T offset_UE1 and T offset_UE2 Less than time offset_max And among them T offset_UE1 ≠T offset_UE2 RAN-Sat 105 starts a 450B timer for each UE. When the corresponding timer for a UE expires, RAN-Sat 105 disconnects the RRC connection between that UE and RAN-Sat 105. Subsequently, each UE sends a 442 registration request and continues as previously... Figure 4A As described in [the text].

[0054] Figure 4C Example 400C is largely similar to scenario 400A, but here, S-AMF 164 sends 420C to RAN-Sat 105, including FL handover for UE 102. time_offset_max The value of the N2 message. Based on the received 420C time_offset_max The value, RAN-Sat 105 for UE 102, determines the timer duration to be less than 450C. time_offset_max The random value. RAN-Sat 105 starts a timer for 450C for UE 102, and when the timer expires, terminates the RRC connection with UE 102.

[0055] Figure 4D Scenario 400D, which is largely similar to Scenario 400A, is illustrated below, with differences discussed below. S-AMF164A sends a 410D UE configuration update command message to UE 102, which may include FL handover assistance information and / or configuration update indications as discussed in reference event 410A, and also includes information for FL handover. time_offset_max Value. S-AMF 164A can only include this value if UE 102 will require an AMF change after an FL handover event. time_offset_max value.

[0056] If the UE configuration update command message includes time_offset_max If the value is less than 451, then UE 102 will determine the timer duration as less than 451. time_offset_max The random value is then used. Then, UE 102 activates timer 451 with the determined timer value, and when the timer expires, UE 102 transitions to CM-idle state by requesting RRC disconnection from RAN-Sat 105 or sending a deregistration request message to S-AMF164A to deregister from CN 110A.

[0057] Now for reference Figures 5A to 5D In some implementations, UE 102 can receive FL handover assistance information in broadcast messages such as System Information Blocks (SIBs).

[0058] First refer to Figure 5A In scenario 500A, RAN-Sat 105 broadcasts FL handover information for 504A. RAN-Sat 105 can generate this FL handover information locally based on ephemeris data, or receive the FL handover information from the O&M server. Then, UE102 can detect the upcoming FL handover event based on the received FL handover information.

[0059] FL handover information can depend on the FL handover location and / or specific time. For example, FL handover information can indicate the FL handover area range represented by ephemeris information (e.g., according to TS 38.331). In this case, UE 102 can determine the duration of the FL handover period and / or the start time of the FL handover event. In another implementation, the FL handover information specifies the duration of the FL handover period and / or the start time of the FL handover event.

[0060] Before the FL handover event begins, UE 102 sends a registration request message (515) to S-AMF 164A, including a request for guidance regarding the FL handover event. In one implementation, the registration request message also includes the duration of the FL handover period and / or the start time of the FL handover event, determined by UE 102 based on the FL handover information in the broadcast message. In another implementation, the registration request message includes an FL handover indication to inform S-AMF 164A that an FL handover event is imminent and that UE 102 requires guidance related to the FL handover event. In yet another implementation, the registration request message indicates the duration of the unavailability period. UE 102 can implement this method similarly to the discussion above regarding unavailability period characteristics. Specifically, 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 conjunction with enhanced support for unavailability period characteristics.

[0061] In response to receiving a 515 registration request message, the S-AMF 164A determines whether a change to the 507 AMF is necessary for a given FL handover event, and, if applicable, generates 507 FL handover assistance information. (This is consistent with the previous text.) Figure 4A Similar to the discussion above, FL handover assistance information may include dedicated FL handover timing assistance IE, FL handover indication, or enhanced unavailability period information as discussed above. The S-AMF 164A can generate this information based on local configuration, information received from RAN-Sat 105, and / or information from the O&M server.

[0062] In addition, and also with Figure 4A Similar to the scenario, S-AMF 164A can determine that UE 102 needs an AMF change due to a change in the service area after a FL handover event, and includes an indication in the UE configuration update command that UE 102 should perform a mobility registration update after the FL handover event is completed. This indication can be a configuration update indication as discussed above or another suitable indication, such as an FL handover update indication. Therefore, S-AMF 164A can omit this indication in response to determining that an AMF change after the FL handover event is unnecessary.

[0063] Then, S-AMF 164A includes FL handover assistance information in the registration acceptance message and sends a 516A registration acceptance message to RAN-Sat 105 within the N2 message. RAN-Sat 105 then sends a 517A registration acceptance message with FL handover assistance information to UE 102.

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

[0065] Next, refer to Figures 5B to 5D Discussion in Figure 5A Several methods for implementing overload control in scenarios similar to the one described above. Figures 4B to 4D Similar to this approach, AMF can implement overload control to distribute NAS signaling to and from the UE during FL handover events.

[0066] refer to Figure 5B Scenario 500B is largely similar to Scenario 500A. However, here, RAN-Sat 505 broadcasts 504B, which includes not only FL handover information but also the maximum offset time value for FL handover. time_offset_max SIB. Based on time_offset_max The RAN-Sat 105, for each affected UE including UE 102, determines the corresponding timer duration to be less than 550B. time_offset_max A random value (similar to event 450B discussed above). When the corresponding timer for a UE expires, RAN-Sat 105 disconnects the RRC connection between the UE and RAN-Sat 105. After the handover timer has expired (and therefore the FL handover period has ended), and in some implementations, when the value is less than... time_offset_max After the timer expires, UE 102 can send a 542 registration request message to T-AMF 164B following the addition of a random timer value. After the timer expires, the UE sends the 542 registration request and continues as previously... Figure 5A As described in [the text].

[0067] Figure 5C Scenario 500C is illustrated, which is broadly similar to Scenario 500A. However, here, S-AMF 164A sends 516C to RAN-Sat 105, including the maximum offset time specific to UE 102. time_offset_max The N2 message. Based on time_offset_max The value, RAN-Sat 105 for UE 102, determines the timer duration to be less than 550C. time offset_maxThe random value (similar to event 450C discussed above). RAN-Sat 105 starts a timer for 550C for UE 102, and when the timer expires, terminates the RRC connection with UE 102.

[0068] Figure 5D Example 500D is largely similar to scenario 500A, but in this scenario, S-AMF 164A sends 516D N2 message containing a registration acceptance message to RAN-Sat 105. This registration acceptance message includes FL handover assistance information and maximum offset time. time_offset_max RAN-Sat 105 then sends a 517D registration acceptance message to UE 102. If the UE configuration update command message includes... time_offset_max If the value is less than 451, then UE 102 will determine the timer duration as less than 451. time_offset_max The random value. Then, UE 102 activates 551 with in time_offset_max A timer with a randomly selected value within a range, and upon the expiration of this timer, UE 102 transitions to the CM-idle state (similar to event 451 discussed above) by requesting RRC disconnection from RAN-Sat 105 or sending a deregistration request message to S-AMF 164A to deregister from CN 110A. UE 102 can then have a timer with a randomly selected value within a range. time_offset_max A 542 registration request message is sent after the timer for a randomly selected value within the range has expired and after the FL switching timer has expired (and therefore the FL switching period has ended).

[0069] Now for reference Figure 6 Scene 600 is largely similar to Scenes 400A-D and 500A-D discussed above, with the differences or changes discussed below.

[0070] RAN-Sat 105 provides UE 102 (see, for example, events 504A or 405B) or S-AMF 164A (see, for example, events 402A or 402B) with 604 FL handover event information. S-AMF 164A can also obtain information related to the FL handover event from the O&M server or location configuration. UE 102 (see, for example, event 505) or S-AMF 164A (see, for example, events 402A or 402B) determines or predicts whether the 605 FL handover event is imminent (i.e., will occur in the near future).

[0071] UE 102 and S-AMF 164A negotiate FL handover event parameters or more generally FL handover assistance information (see, for example, events 410A / 412, 410D / 412, 515 / 516A / 517A, 515 / 516C / 517A, 515 / 516D / 517D). FL handover event parameters may include the duration of the FL handover period and / or the start time of the FL handover period, as discussed above in conjunction with FL handover assistance information. S-AMF 164A may also determine whether the FL handover event 610 necessitates a change in the AMF or MME, and in some cases, instruct the UE to perform a registration request procedure. In some cases, procedure 610 includes a procedure similar to procedure 516 discussed above.

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

[0073] Figure 7 Example method 700 is illustrated, which a UE (e.g., UE 102) can implement to determine whether and when to send a registration update to the core network. At block 710, the UE receives auxiliary information related to a FL handover at a currently serving non-terrestrial RAN node, such as a satellite (see, for example, events 410A, 410D, 504A, 504B). At block 741, the UE processes the received auxiliary information to determine whether a registration update is required for the FL handover event.

[0074] Optionally, at block 732, the UE also determines the timing for performing the registration update (see, for example, events 432 and 532). This timing may correspond to the duration of the FL handover period. In some cases, to support UE-side overload control, the UE also determines 751. time_offset_max A random timer value within the range (see events 451 and 551, for example) causes the registration update to begin after the FL switching period ends and after the overload control timer with the random timer value expires.

[0075] At box 733, if the UE determines that a registration update is needed, the process proceeds to box 742, where the UE sends a registration update to the core network (specifically, the target or “new” core network) via the serving non-terrestrial RAN node (see, for example, events 442 and 542). Then, at box 770, the UE can restore one or more services by sending a service request message via the non-terrestrial RAN node. As the process proceeds from box 433 through box 742 to box 770, the service request message travels to the target core network.

[0076] At box 733, if the UE determines that it does not need to register for an update, the process proceeds directly to box 770. In this case, the service request message can proceed to the source core network.

[0077] Figure 8 Example method 800 is illustrated, which a CN node (e.g., S-AMF 164A) can implement to coordinate or facilitate the handling of FL handover events at a UE (e.g., UE 102). For convenience, method 800 is discussed below with reference to the AMF rather than the CN node.

[0078] At box 802, the AMF predicts the upcoming FL handover event (see, for example, events 402A, 402B, 507). At box 809, the AMF determines for the UE that the upcoming FL handover event will require a change in the CN (specifically, the AMF) (see, for example, events 402A, 402B, 507). Next, at box 810, the AMF generates and sends auxiliary information related to the FL handover event to the UE (see, for example, events 410A, 410D, 516A, 516C, 516D). In some implementations, box 810 also includes box 816, where the AMF further includes the maximum offset time value for the FL handover in the message to the UE. time_offset_max (See, for example, events 410D and 516D).

[0079] The following list of examples illustrates various embodiments explicitly contemplated in this disclosure.

[0080] Example 1. A method implemented in a user equipment (UE), the method comprising: receiving, via a serving link, auxiliary information relating to a node switching from a first feeder link (FL) to a second FL to connect to a second core network (CN), the node being coupled to a first CN via the first FL; and determining, based on the auxiliary information, whether to perform a registration update.

[0081] Example 2. The method as described in Example 1, wherein the auxiliary information indicates the duration of the switching event including the switching.

[0082] Example 3. The method as described in Example 1, wherein the auxiliary information indicates the start time of the switching event including the switching.

[0083] Example 4. The method as described in any of the preceding examples, wherein the auxiliary information is included in an information element IE that is exclusively dedicated to transmitting FL switching auxiliary information.

[0084] Example 5. The method as described in any one of Examples 1 to 3, wherein the auxiliary information is indicated in the unavailability period information.

[0085] Example 6. The method as described in any of the preceding examples, wherein the auxiliary information includes an indication that the switching is about to begin.

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

[0087] Example 8. The method as described in Example 1, wherein the auxiliary information is received from the first CN via the RAN in a Non-Access Stratum (NAS) message.

[0088] Example 9. The method described in Example 8, wherein the NAS message is a UE configuration update command message.

[0089] Example 10. The method described in Example 8, wherein the NAS message is a registration acceptance message.

[0090] Example 11. The method of any one of Examples 1 to 5 or 8, further comprising: receiving an indication related to the handover event in the cell of the node via a broadcast message.

[0091] Example 12. The method of Example 11 further includes: sending a request for the auxiliary information to the first CN in response to the indication associated with the switching event; and receiving the auxiliary information from the first CN in response to the request.

[0092] Example 13. The method as described in any of the preceding examples further includes: determining when to perform the registration update based on the auxiliary information.

[0093] Example 14. The method as described in Example 13 further includes: starting an FL switching timer having a duration determined based on the auxiliary information; and sending a registration request message to the second CN after the FL switching timer expires.

[0094] Example 15. The method as described in Example 13 further includes: starting an FL handover timer having a duration included in the configuration of the UE; and sending a registration request message to the second CN after the FL handover timer expires.

[0095] Example 16. The method of any one of Examples 1 to 7, wherein: an indication of a maximum time offset for delaying the execution of the registration update is received; an overload timer is started having a duration corresponding to a random value less than the maximum time offset; and the execution of the registration update is initiated after the overload timer expires.

[0096] Example 17. The method as described in Example 16, wherein the maximum time offset is received from the first CN in the UE configuration update command message.

[0097] Example 18. The method as described in Example 17, wherein the UE configuration update command message further includes the auxiliary information.

[0098] Example 19. The method as described in Example 16, wherein the maximum time offset is received from the first CN in a registration acceptance message.

[0099] Example 20. The method as described in Example 19, wherein the registration acceptance message further includes the auxiliary information.

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

[0101] Example 22. The method as described in any of the preceding examples further includes: transitioning to a CM-idle state in response to determining that the registration update will be performed.

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

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

[0104] 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 handover event, during which a node of a non-terrestrial radio access network (RAN) performs a handover from a first feeder link (FL) connecting the node to the first CN to a second FL to connect the node to the second CN; and sending auxiliary information to a UE operating in the cell of the node relating to the performance of a registration update due to the FL handover event.

[0105] Example 26. The method as described in Example 25, wherein: the auxiliary information indicates at least one of (i) the duration of the switching event or (ii) the start time of the switching event.

[0106] Example 27. The method as described in Example 25 or 26, wherein the auxiliary information is included in an information element (IE) exclusively dedicated to transmitting FL switching auxiliary information.

[0107] Example 28. The method as described in Example 25 or 26, wherein the auxiliary information is included in the unavailability period information.

[0108] Example 29. The method of any one of Examples 25 to 28, wherein the auxiliary information includes an indication that the switching event is about to begin.

[0109] Example 30. The method of any one of Examples 25 to 29, wherein the auxiliary information is sent in a Non-Access Stratum (NAS) message.

[0110] Example 31. The method as described in any one of Examples 25 to 30, wherein the prediction of the upcoming switching event is based on ephemeris data.

[0111] Example 32. The method of any one of Examples 25 to 31, further comprising: in response to a prediction that the upcoming handover event will require the UE to register with the second CN, including in the auxiliary information an indicator instructing the UE to perform the registration update.

[0112] Example 33. The method of any one of Examples 25 to 32 further includes: receiving a request for the auxiliary information from the UE; wherein the transmission of the auxiliary information is in response to the request for the auxiliary information.

[0113] Example 34. The method of any one of Examples 25 to 33 further includes: sending an indication to the UE of a maximum time offset for delaying the execution of the registration update.

[0114] Example 35. The method of any one of Examples 25 to 34 further includes: sending a non-UE-specific indication to the node for delaying the execution of the registration update by a maximum time offset.

[0115] Example 36. A node of a core network (CN) includes processing hardware configured to implement the method according to any one of Examples 25 to 35.

[0116] The following descriptions can be applied to the descriptions above.

[0117] Generally, a description for one of the above figures can be applied to another. Any event or box described above may be optional. For example, an event or box with a dashed line may be optional. In some implementations, "message" is used and "information element (IE)" can be used instead of "message," and vice versa. In some implementations, "IE" is used and "field" can be used instead of "IE," and vice versa. In some implementations, "configurations" or "configuration parameters" can be used instead of "configuration," and vice versa. "Base station," "gNB," "6G base station," "evolved gNB," or "6G gNB" can be used instead of "eNB."

[0118] User devices (e.g., UE 102) that can implement the technologies disclosed herein can be any suitable device capable of wireless communication, such as smartphones, tablet computers, laptop computers, mobile game consoles, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, or broadband routers. Furthermore, in some cases, the user device can be embedded in electronic systems such as the main unit of a vehicle or an advanced driver assistance system (ADAS). Additionally, the user device can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0119] Some embodiments described in this disclosure include logic or multiple components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a certain way. A hardware module may include a dedicated circuit system or logic that is persistently configured (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC), digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also include programmable logic or circuit systems that are temporarily configured by software to perform certain operations (e.g., as encompassed within 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.

[0120] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof are intended to cover non-exclusive inclusion. For example, a process, method, article of manufacture, or apparatus that includes a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article of manufacture, or apparatus. Furthermore, unless expressly stated to the contrary, “or” means inclusive or rather, not exclusive. For example, condition A or B is satisfied by either: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

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

Claims

1. A method implemented in a user equipment (UE), the method comprising: The node receives auxiliary information from a non-terrestrial radio access network (RAN) via a serving link, relating to the node's switch from a first feeder link (FL) to a second FL to connect to a second core network (CN), the node being coupled to the first CN via the first FL; as well as The decision to perform a registration update is based on the aforementioned auxiliary information.

2. The method of claim 1, wherein the auxiliary information indicates the duration of the switching event including the switching.

3. The method of claim 1 or 2, wherein the auxiliary information indicates the start time of the switching.

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

5. The method of claim 1, wherein: The auxiliary information is received from the first CN via the RAN in a Non-Access Stratum (NAS) message.

6. The method according to any one of claims 1 to 3 or 5, further comprising: The node receives an indication related to a handover event, including the handover, in the cell via a broadcast message.

7. The method as described in any of the preceding claims, further comprising: The timing of the registration update is determined based on the auxiliary information.

8. The method of claim 7, further comprising: Start an FL switching timer with a duration determined based on the aforementioned auxiliary information; as well as After the FL switching timer expires, a registration request message is sent to the second CN.

9. The method according to any one of claims 1 to 4, wherein: Receive an indication of the maximum time offset for delaying the execution of the registration update; Start an overload timer with a duration corresponding to a random value less than the maximum time offset; as well as After the overload timer expires, the execution of the registration update is initiated.

10. A method implemented in a node of a first core network (CN) of a cellular communication system, the method comprising: An upcoming handover event is anticipated, during which a node of the non-terrestrial radio access network (RAN) performs a handover from a first feeder link (FL) connecting the node to the first CN to a second FL in order to connect the node to the second CN. as well as Send auxiliary information related to the registration update performed due to the FL handover event to the UE operating in the cell of the node.

11. The method of claim 10, wherein: The auxiliary information indicates at least one of (i) the duration of the switching event or (ii) the start time of the switching event.

12. The method of claim 10 or 11, further comprising: In response to the prediction that the upcoming handover event will require the UE to register with the second CN, the auxiliary information includes an indicator instructing the UE to perform the registration update.

13. The method of any one of claims 10 to 12, further comprising: Send an indication to the UE of the maximum time offset for delaying the execution of the registration update.

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

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

Images