WO2025037179A1 - Mechanisms for support of satellite or feeder link switch with unchanged pci and carrier frequency - Google Patents

Abstract

A method performed by a user equipment for performing a cell switch is provided. The method comprises: receiving, from a network node, assistance information for performing the cell switch and performing the cell switch based on the assistance information, The assistance information comprises one or more of: information related to general properties of the cell switch; information related to the timing of the cell switch; information related to the satellite orbit and feeder link propagation delay after the cell switch; information related to the difference in timing; information related to the timing of the SSB transmissions after the cell switch; information related to the location and coverage of the new cell; and information related to the provision or transfer of assistance information or configuration information to the UE.

Description

MECHANISMS FOR SUPPORT OF SATELLITE OR FEEDER LINK SWITCH WITH UNCHANGED PCI AND CARRIER FREQUENCY CROSS REFERENCE TO RELATED APPLICATION [0001] This application claims priority to PCT Application No. PCT/C2023/112507 filed on August 11, 2023, and PCT Application No. PCT/CN2023/117136 filed on September 6, 2023, and titled “MECHANISMS FOR SUPPORT OF SATELLITE OR FEEDER LINK SWITCH WITH UNCHANGED PCI AND CARRIER FREQUENCY.” The contents of both applications are hereby incorporated by reference in their entirety for all purposes. FIELD [0002] This present disclosure relates generally to telecommunication systems and methods, and in particular to improving a cell switching process of a user equipment. BACKGROUND [0003] Satellite networks can complement mobile networks on the ground by providing connectivity to areas that may be underserved using terrestrial networks. Additionally, satellite networks may improve mobile networks with respect to multicast and/or broadcast services. Satellites may communicate with terrestrial gateways configured to connect the satellites to a base station or a core network. [0004] A base station may facilitate connection between satellites to user equipment (UE). For example, the base station may facilitate transition of UE’s connection between different satellites. [0005] As the resurgence of satellite communications continues, different plans for satellite networks have been announced and/or defined. Satellite communications may be applied in various target services, from backhaul and fixed wireless, to transportation, to outdoor mobile, to Internet of Things (IoT). Satellite networks can complement mobile networks on the ground by providing connectivity to underserved areas and multicast/broadcast services. [0006] To benefit from the strong mobile ecosystem and economy of scale, adapting the terrestrial wireless access technologies including Long Term Evolution (LTE) and New Radio (NR) for satellite networks is drawing significant interest. However, cell switches with unchanged carrier frequency and physical cell identify (PCI) are immature and still lacks many of the detailed mechanisms needed to make it work. SUMMARY [0007] Various computer-implemented systems, methods, and articles of manufacture for cell switch with unchanged PCI are described herein. Cell switches with unchanged PCI may provide certain improvements such as seamless handover process, simplified beam management, and/or enhanced quality of service. [0008] In one embodiment, a method performed by a UE for performing a cell switch is disclosed. The method comprises receiving, from a network node, cell-switching assistance information for performing the cell switch with unchanged physical cell identity (PCI). The method further comprises performing the cell switch from a first cell to a second cell based on the cell-switching assistance information. [0009] In one embodiment, a UE, comprising processing circuitry is configured to perform the method above. [0010] In one embodiment, a method performed by a network node for facilitating a UE to perform a cell switch from a first cell to a second cell is disclosed. The method comprises sending cell-switching assistance information with unchanged PCI. [0011] In one embodiment, a network node, comprising processing circuit is configured to perform the method above. BRIEF DESCRIPTION OF THE DRAWINGS [0012] For a better understanding of the various described embodiments, reference should be made to the Detailed Description below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures. [0013] Figure 1 illustrates an exemplary wireless network in accordance with some embodiments. [0014] Figure 2 illustrates an exemplary user equipment in accordance with some embodiments. [0015] Figure 3 illustrates an exemplary network node in accordance with some embodiments. [0016] Figure 4 illustrates an exemplary virtualization environment in accordance with some embodiments. [0017] Figure 5 illustrates an example architecture of a satellite network with a bent pipe transponders or transparent payload architecture in accordance with some embodiments. [0018] Figure 6 illustrates an example satellite orbit including orbital elements in accordance with some embodiments. [0019] Figure 7 is a flowchart illustrating an example method for a handover operation. [0020] Figure 8 is a flowchart illustrating another example method for a handover operation. [0021] Figure 9A is a flowchart illustrating an error that may occur during a handover process, in which conditional handovers may be applicable. [0022] Figure 9B is a flowchart illustrating another error that may occur during a handover process, in which conditional handovers may be applicable. [0023] Figure 10 illustrates a message diagram for an inter-network Conditional Handover in accordance with some embodiments. [0024] Figure 11 illustrates another message diagram for an inter-network Conditional Handover in accordance with some embodiments. [0025] Figure 12 is a flowchart of an example method, performed by a user equipment, for performing a cell switch according to some embodiments. [0026] Figure 13 illustrates a flow chart of an example method, performed by a network node, for performing a cell switch according to some embodiments. DETAILED DESCRIPTION [0027] Certain aspects of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. This concept may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the concept to those skilled in the art. [0028] Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise: [0029] The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. Thus, as described below, various embodiments of the invention may be readily combined, without departing from the scope of the invention. [0030] As used herein, the term “or” is an inclusive “or” operator and is equivalent to the term “and/or,” unless the context clearly dictates otherwise. [0031] The term “based on” is not exclusive and allows for being based on additional factors not described unless the context clearly dictates otherwise. [0032] As used herein, and unless the context dictates otherwise, the term “coupled to” is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms “coupled to” and “coupled with” are used synonymously. Within the context of a networked environment where two or more components or devices are able to exchange data, the terms “coupled to” and “coupled with” are also used to mean “communicatively coupled with”, possibly via one or more intermediary devices. [0033] In addition, throughout the specification, the meaning of “a”, “an”, and “the” includes plural references, and the meaning of “in” includes “in” and “on”. [0034] Although some of the various embodiments presented herein constitute a single combination of inventive elements, it should be appreciated that the inventive subject matter is considered to include all possible combinations of the disclosed elements. As such, if one embodiment comprises elements A, B, and C, and another embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly discussed herein. Further, the transitional term “comprising” means to have as parts or members, or to be those parts or members. As used herein, the transitional term “comprising” is inclusive or open-ended and does not exclude additional, unrecited elements or method steps. [0035] In various embodiments, the devices, instruments, systems, and methods described herein may be used to improve cell-switching operations of UE. The UE may obtain cell- switching assistance information from the network node. Based on the cell-switching assistance information, the UE performs the cell switch with unchanged PCI. [0036] It is noted that description herein is not intended as an extensive overview, and as such, concepts may be simplified in the interests of clarity and brevity. Any process or method or corresponding steps of any process or method described in this application may be performed in any order and may omit any of the steps in the process. Processes or methods may also be combined with other processes or steps of other processes, in part or in whole. Parts of processes or methods, or corresponding steps may be combined with other parts of processes or methods, or corresponding steps. [0037] Figure 1 shows an example of a communication system 100 in accordance with some embodiments. [0038] In the example, the communication system 100 includes a telecommunication network 102 that includes an access network 104, such as a radio access network (RAN), and a core network 106, which includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be generally referred to as network nodes 110), or any other similar 3^rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 102, including one or more network nodes 110 and/or core network nodes 108. [0039] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may be generally referred to as UEs 112) to the core network 106 over one or more wireless connections. [0040] Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 100 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system. [0041] The UEs 112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 110 and other communication devices. Similarly, the network nodes 110 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 112 and/or with other network nodes or equipment in the telecommunication network 102 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 102. [0042] In the depicted example, the core network 106 connects the network nodes 110 to one or more hosts, such as host 116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 106 includes one more core network nodes (e.g., core network node 108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF). [0043] The host 116 may be under the ownership or control of a service provider other than an operator or provider of the access network 104 and/or the telecommunication network 102, and may be operated by the service provider or on behalf of the service provider. The host 116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. [0044] As a whole, the communication system 100 of Figure 1 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. [0045] In some examples, the telecommunication network 102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 102. For example, the telecommunications network 102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive IoT services to yet further UEs. [0046] In some examples, the UEs 112 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 104. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, e.g., being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio – Dual Connectivity (EN- DC). [0047] In the example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112c and/or 112d) and network nodes (e.g., network node 110b). In some examples, the hub 114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 114 may be a broadband router enabling access to the core network 106 for the UEs. As another example, the hub 114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 110, or by executable code, script, process, or other instructions in the hub 114. As another example, the hub 114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 114 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy IoT devices. [0048] The hub 114 may have a constant/persistent or intermittent connection to the network node 110b. The hub 114 may also allow for a different communication scheme and/or schedule between the hub 114 and UEs (e.g., UE 112c and/or 112d), and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and/or one or more UEs via a wired connection. Moreover, the hub 114 may be configured to connect to an M2M service provider over the access network 104 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 110 while still connected via the hub 114 via a wired or wireless connection. In some embodiments, the hub 114 may be a dedicated hub – that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub – that is, a device which is capable of operating to route communications between the UEs and network node 110b, but which is additionally capable of operating as a communication start and/or end point for certain data channels. [0049] Figure 2 shows a UE 200 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE. [0050] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and/or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). [0051] The UE 200 includes processing circuitry 202 that is operatively coupled via a bus 204 to an input/output interface 206, a power source 208, a memory 210, a communication interface 212, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 2. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc. [0052] The processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 210. The processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 202 may include multiple central processing units (CPUs). [0053] In the example, the input/output interface 206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device. [0054] In some embodiments, the power source 208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 208 may further include power circuitry for delivering power from the power source 208 itself, and/or an external power source, to the various parts of the UE 200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 208 to make the power suitable for the respective components of the UE 200 to which power is supplied. [0055] The memory 210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 210 includes one or more application programs 214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 216. The memory 210 may store, for use by the UE 200, any of a variety of various operating systems or combinations of operating systems. [0056] The memory 210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD- DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and/or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 210 may allow the UE 200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 210, which may be or comprise a device-readable storage medium. [0057] The processing circuitry 202 may be configured to communicate with an access network or other network using the communication interface 212. The communication interface 212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 222. The communication interface 212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 218 and/or a receiver 220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 218 and receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software or firmware, or alternatively be implemented separately. [0058] In the illustrated embodiment, communication functions of the communication interface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol/internet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth. [0059] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient). [0060] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input. [0061] A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and/or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 200 shown in Figure 2. [0062] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. [0063] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators. [0064] Figure 3 shows a network node 300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU). [0065] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). [0066] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs). [0067] The network node 300 includes a processing circuitry 302, a memory 304, a communication interface 306, and a power source 308. The network node 300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 304 for different RATs) and some components may be reused (e.g., a same antenna 310 may be shared by different RATs). The network node 300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 300. [0068] The processing circuitry 302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 300 components, such as the memory 304, to provide network node 300 functionality. [0069] In some embodiments, the processing circuitry 302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 302 includes one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314. In some embodiments, the radio frequency (RF) transceiver circuitry 312 and the baseband processing circuitry 314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 312 and baseband processing circuitry 314 may be on the same chip or set of chips, boards, or units. [0070] The memory 304 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer- executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 302. The memory 304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 302 and utilized by the network node 300. The memory 304 may be used to store any calculations made by the processing circuitry 302 and/or any data received via the communication interface 306. In some embodiments, the processing circuitry 302 and memory 304 is integrated. [0071] The communication interface 306 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 306 comprises port(s)/terminal(s) 316 to send and receive data, for example to and from a network over a wired connection. The communication interface 306 also includes radio front-end circuitry 318 that may be coupled to, or in certain embodiments a part of, the antenna 310. Radio front-end circuitry 318 comprises filters 320 and amplifiers 322. The radio front-end circuitry 318 may be connected to an antenna 310 and processing circuitry 302. The radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302. The radio front-end circuitry 318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 320 and/or amplifiers 322. The radio signal may then be transmitted via the antenna 310. Similarly, when receiving data, the antenna 310 may collect radio signals which are then converted into digital data by the radio front-end circuitry 318. The digital data may be passed to the processing circuitry 302. In other embodiments, the communication interface may comprise different components and/or different combinations of components. [0072] In certain alternative embodiments, the network node 300 does not include separate radio front-end circuitry 318, instead, the processing circuitry 302 includes radio front-end circuitry and is connected to the antenna 310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 312 is part of the communication interface 306. In still other embodiments, the communication interface 306 includes one or more ports or terminals 316, the radio front-end circuitry 318, and the RF transceiver circuitry 312, as part of a radio unit (not shown), and the communication interface 306 communicates with the baseband processing circuitry 314, which is part of a digital unit (not shown). [0073] The antenna 310 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 310 may be coupled to the radio front-end circuitry 318 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 310 is separate from the network node 300 and connectable to the network node 300 through an interface or port. [0074] The antenna 310, communication interface 306, and/or the processing circuitry 302 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna 310, the communication interface 306, and/or the processing circuitry 302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment. [0075] The power source 308 provides power to the various components of network node 300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 300 with power for performing the functionality described herein. For example, the network node 300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 308. As a further example, the power source 308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. [0076] Embodiments of the network node 300 may include additional components beyond those shown in Figure 3 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 300 may include user interface equipment to allow input of information into the network node 300 and to allow output of information from the network node 300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 300. [0077] Figure 4 is a block diagram illustrating a virtualization environment 400 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. [0078] Applications 402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. [0079] Hardware 404 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 408a and 408b (one or more of which may be generally referred to as VMs 408), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 406 may present a virtual operating platform that appears like networking hardware to the VMs 408. [0080] The VMs 408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 406. Different embodiments of the instance of a virtual appliance 402 may be implemented on one or more of VMs 408, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. [0081] In the context of NFV, a VM 408 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 408, and that part of hardware 404 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 408 on top of the hardware 404 and corresponds to the application 402. [0082] Hardware 404 may be implemented in a standalone network node with generic or specific components. Hardware 404 may implement some functions via virtualization. Alternatively, hardware 404 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 410, which, among others, oversees lifecycle management of applications 402. In some embodiments, hardware 404 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 412 which may alternatively be used for communication between hardware nodes and radio units. [0083] Figure 5 shows an example architecture of a satellite network 500 with a bent pipe transponders or transparent payload architecture, in accordance with some embodiments of the present disclosure. A satellite network may also be referred to as a satellite radio access network, which may include a satellite, an earth-based gateway, a feeder link, and an access link. A satellite refers to a space-borne platform. An earth-based gateway connects the satellite to a base station or a core network, depending on the choice of architecture. A feeder link refers to the link between a gateway and a satellite. An access link, or service link, that refers to the link between a satellite and a UE. In some embodiments as shown in Figure. 5, the satellite network 500 may include a satellite 502. In some embodiments, the satellite 502 may be characterized as different types of satellites based on orbit altitude of the satellite 502. For example, the satellite 502 may be categorized as low earth orbit (LEO), medium Earth orbit (MEO), or geostationary Earth orbit (GEO) satellite. LEO satellites have typical heights ranging from 250 – 1,500 km, with orbital periods ranging from 90 – 120 minutes. MEO satellites have typical heights ranging from 1,500 – 35,786 km, with orbital periods, P_MEO, in the range 2 hours < PMEO < 24 hours (MEO and LEO are also known as Non-Geo Synchronous Orbit (NGSO) type of satellite). GEO satellites have heights at about 35,786 km, with an orbital period of 24 hours (also known as a Geo Synchronous Orbit (GSO) type of satellite). The significant orbit height means that satellite systems are characterized by a path loss that is significantly higher than what is expected in terrestrial networks. To overcome the pathloss it is often required that the access and feeder links are operated in line-of-sight conditions, and that the UE is equipped with an antenna offering high beam directivity. [0084] In some embodiments, the satellite 502 may be configured to communicate with a gateway (GW) 504. In some embodiments, the satellite 502 may communicate with the gateway 504 via a feeder link 503. In some embodiments, the gateway 504 may be configured to connect the satellite 502 to a base station 506 (e.g., a gNB) or a core network. in the present disclosure, a reference to a gNB may include a reference to a base station. The network node may be integrated in the gateway or connected to the gateway 504 via a terrestrial connection (e.g., wire, optic fiber, wireless link). [0085] In some embodiments, the satellite 502 may further communicate with at least one device 508 (e.g., a user equipment such as the UE 112 of Figure 1). In some embodiments, the satellite 502 may communicate with the device via an access link (also referred to as service link) 507. [0086] Two basic architectures can be distinguished for satellite communication networks, depending on the functionality of the satellites in the system. The two basic architectures are transparent payload architecture and regenerative payload architecture. [0087] For the transparent payload architecture (also referred to as bent pipe architecture), a satellite (e.g., the satellite 502) may forward the received signal between the terminal and the network equipment on the ground with only amplification and a shift from uplink frequency to downlink frequency. When applied to general 3GPP architecture and terminology, the transparent payload architecture means that the network node (base station in NR) is located on the ground and the satellite forwards signals/data between the network node and the UE. [0088] For the regenerative payload architecture, a satellite (e.g., the satellite 502) includes on-board processing to demodulate and decode the received signal and regenerate the signal before sending it back to the Earth. When applied to general 3GPP architecture and terminology, the regenerative payload architecture means that the network node is located in the satellite. [0089] A communication satellite typically generates several beams over a given area. The footprint of a beam is usually in an elliptic shape, which has been traditionally considered as a cell (but a cell having multiple beams is not precluded). The footprint of a beam is also often referred to as a spotbeam 510. The spotbeam 510 may move over the Earth surface with the satellite movement (and the Earth’s rotation) or maybe Earth fixed with some beam pointing mechanism used by the satellite to compensate for its motion. The size of a spotbeam depends on the system design and may range from tens of kilometers to a few thousands of kilometers. [0090] A non-terrestrial network (NTN) beam may in comparison to the beams observed in a terrestrial network provide a very wide footprint and may cover an area outside of the area defined by the served cell. Beam covering adjacent cells will overlap and cause significant levels of intercell interference, resulting from the slow decrease of the signal strength in the outwards radial direction. This is due in part to the high elevation angle and long distance to the network-side (satellite-borne) transceiver, which, compared with terrestrial cells, results in a comparatively small relative difference between the distance from the cell center to the satellite and the distance from a point at the cell edge to the satellite. To overcome the large levels of interference, a typical approach in NTN is to configure different cells with different carrier frequencies and polarization modes. [0091] Three types of beams or cells may be supported in NTN: (1) Earth-fixed beams/cells: provisioned by beam(s) continuously covering the same geographical areas all the time (e.g., in the case of GEO satellites); (2) Quasi-Earth-fixed beams/cells: provisioned by beam(s) covering one geographic area for a limited period and a different geographic area during another period (e.g., in the case of NGSO satellites generating steerable beams); and (3) Earth-moving beams /cells: provisioned by beam(s) whose coverage area slides over the earth surface (e.g., in the case of NGSO satellites generating fixed or non-steerable beams). [0092] Throughout this disclosure, the terms beam and cell may be used interchangeably, unless explicitly noted otherwise. [0093] A particular satellite may be configured to cover the same area on the Earth for a limited time, unless the satellite is in a geostationary orbit. In the case of moving cells, each cell moves along the surface of the Earth as the satellite serving it moves along its orbit above. Accordingly, as seen from the ground, cells gradually replace each other over any given area. In the case of quasi-Earth-fixed cells, the cell area remains fixed to the same geographical area, regardless of satellite movements. To facilitate such characteristics, a serving satellite may be configured to have means for dynamically directing its beam(s), so that the same area of the Earth is covered despite the satellite’s movement. However, since the satellites orbit around the Earth, it is inevitable that different satellites will have the task of covering a certain geographical cell area at different time periods. When this task is switched from one satellite to another, this in principle means that one cell is replaced by another, although covering the same area (often referred to as a cell switch). [0094] As a consequence, all UEs connected to a first cell (e.g., UEs in Radio Resource Control Connected (RRC_CONNECTED) state) may need to be handed over (or otherwise moved, e.g., using RRC connection reestablishment) from the first cell to a second cell, and all UEs camping on the first cell (e.g., UEs in RRC_IDLE or RRC_INACTIVE state) may have to perform cell reselection to the second cell. Instances in which the satellite 502 serving a particular area is changed, such that the first cell disappears and the second cell appears, may be referred to as a satellite switch. A consequence of a satellite switch is that both the service link (e.g., the link between the UE and the satellite) and the feeder link (e.g., the link between the satellite and the gateway 504/ network node or GW/ network node) are switched. [0095] A similar situation occurs in conjunction with feeder link switches, e.g., when the serving satellite remains the same, but its connection to the ground changes from one (old) GW/ network node to another (new) GW/ network node. Also, in this case there is a switch between an old cell and a new cell (e.g., the old cell is replaced by a new cell). [0096] Satellite switches and feeder link switches can both be referred to with the umbrella term “cell switch”. [0097] In terms of such cell switches, there may be two alternative principles: 1) hard switch; and 2) soft switch. With a hard switch, the cell switch from the first to the second cell may be substantially instantaneous. For example, the second cell may appear substantially at the same time (e.g., with no or small gap in between) as the first cell disappears. This makes a completely-seamless (e.g., interruption free) handover impractical or perhaps impossible and creates a situation which may lead to overload of the access resources in the new cell, due to potential access attempt peaks when many UEs try to access the new cell right after the cell switch. [0098] With a soft switch, there may be a time period during which the first cell and the second cell coexist (e.g., overlap), covering the same geographical area. This coexistence/overlap period may allow some time for connected UEs to perform measurements and to be handed over to the second cell, and for UEs in RRC_IDLE state and RRC_INACTIVE state (e.g., UEs camping in the cell) to reselect the second cell. Thus, the coexistence/overlap period of the two cells facilitates distribution of the access load in the second cell and thereby also provides better conditions for handovers with shorter interruption time. Soft switch is likely to be the most prevalent cell switch principle in quasi-Earth-fixed cell deployments. [0099] Yet another possible deployment option may be referred to as discontinuous coverage. With discontinuous coverage, NGSO (Non-Geostationary Orbit) satellites orbit the Earth, providing coverage to moving or quasi-Earth-fixed cells. What characterizes a discontinuous coverage deployment is that when a satellite ceases to provide coverage in a certain location, another satellite does not immediately take over this task. Instead, the location is left without coverage for a certain time until another satellite (or possibly even the same satellite) starts to provide coverage in the location. Discontinuous coverage can thus be seen as a consequence of sparse satellite deployment. Discontinuous coverage may typically be used during an early phase where the satellite constellation is still being built up and the number of deployed satellites gradually increases. Alternatively, it can be a deployment alternative chosen to reduce the cost of the NTN, e.g., in cases where the targeted customers and applications are insensitive to access delays. In terms of standard specification, special support for discontinuous coverage has so far mainly been taken into account in the specification of the LTE based IoT NTN. [0100] In some embodiments, the network node 506 and the GW 504 may be separate entities which are spatially separate with a non-negligible propagation delay between them. Alternatively, the network node 506 and the GW 504 can be integrated in a single entity, or separate entities but collocated in a way that the propagation delay between them is negligible. The principle and embodiments described in this disclosure are applicable in all cases if the definition (sometimes inaccurate) of the feeder link is the communication link between the satellite and the network node. [0101] Ephemeris data (sometimes referred to as “ephemeris information” or “ephemeris parameters” or just “ephemeris”) is data that allows a UE (or other entity) to determine a satellite’s position and velocity, e.g., the ephemeris data contains parameters related to the satellite’s orbit. There are several different formats defined for ephemeris data. [0102] In some examples, ephemeris data should be provided to the UE, for example to assist with pointing a directional antenna (or an antenna beam) towards the satellite, and to calculate a correct Timing Advance (TA) and Doppler shift. In NR NTN and IoT NTN, ephemeris data is broadcast in the system information (SI) in each cell, included in an NTN specific System Information Block (SIB). [0103] A satellite orbit can be fully described using six parameters. Exactly which set of parameters is chosen can be decided by the user; many different representations are possible. For example, a choice of parameters used often in astronomy is the set (a, ε, i, Ω, ω, t). Here, the semi-major axis a and the eccentricity ε describe the shape and size of the orbit ellipse; the inclination i, the right ascension of the ascending node Ω, and the argument of periapsis ω determine its position in space, and the epoch time t determines a reference time (e.g., the time when the satellites move through periapsis). [0104] For example, Figure 6 shows a satellite orbit 600 including orbital elements illustrating parameters included in one ephemeris data format, in accordance with some embodiments of the present disclosure. In some embodiments, an orbit ellipse 602 may be defined and/or described based on a semi-major axis a and an eccentricity ε. Additionally or alternatively, the orbit ellipse 602 may be defined using inclination i, right ascension of the ascending node Ω, and argument of periapsis ω determine its position in space, and the epoch time t determines a reference time. [0105] As an example of a different parametrization, the Two-Line Element Sets (TLEs) use mean motion n and mean anomaly M instead of a and t. A completely different set of parameters is the position and velocity vector (x, y, z, vx, vy, vz) of a satellite. These are sometimes called orbital state vectors. They can be derived from the orbital elements (and vice versa) since the information they contain is equivalent. All these formats (and many others) are possible choices for the format of ephemeris data to be used in NTN. [0106] Predictions of satellite positions in general degrade with increasing age of the ephemeris data used, due to atmospheric drag, maneuvering of the satellite, imperfections in the orbital models used, etc. Therefore, the publicly available TLE data are updated quite frequently. For example, the update frequency depends on the satellite and its orbit and ranges from weekly to multiple times a day for satellites on very low orbits which are exposed to strong atmospheric drag and need to perform correctional maneuvers often. Even more frequent updates will be used in NR NTN (and IoT NTN) to allow the UE to determine/predict the satellite’s position (and velocity) accurately enough to satisfy the requirements in NTN, e.g., to enable a UE to calculate an accurate enough UE-specific TA. In NR NTN, the ephemeris data and the validity time of the ephemeris data is provided to the UE in the ntn-Config IE in the NTN specific SIB, SIB19. [0107] Propagation delay is an important aspect of satellite communication. Expected impacts of the propagation delay in NTN may be different from the impacts of propagation delay in a terrestrial mobile system. For a bent pipe satellite network, the UE- network node round-trip delay may, depending on the orbit height, range from a few or tens of ms in the case of LEO satellites to several hundreds of ms for GEO satellites. As a comparison, the round-trip delays in terrestrial cellular networks are typically below 1 ms. [0108] The distance between the UE and a satellite can vary significantly, depending on the position of the satellite and thus the elevation angle seen by the UE. The propagation delay may also be highly variable due to the high velocity of the LEO and MEO satellites and change in the order of 10 – 100 µs every second, depending on the orbit altitude and satellite velocity. [0109] The long propagation delays in NTN may have various consequences, one of which being that large Timing Advance (TA) values have to be used (where a TA is the time a UE has to advance its UL transmission in relation to the corresponding frame, slot and symbol in the DL to achieve alignment between the UL and the DL frame/slot/symbol structure at an UL/DL alignment reference point, which typically is the network node). In addition, due to the fast movement of the satellite (excluding GEO satellites), the TA will continuously change and will do so quite rapidly. 3GPP has dealt with these circumstances through a combination of new parameters and introduction of the principle of UE autonomous adaptation of the TA. [0110] To take care of the part of the TA that is common for all UEs in the cell, the satellite broadcasts in the system information (SIB19 in NR NTN and SIB31 in IoT NTN) so-called Common TA information, consisting of a Common TA value. The UE specific part of the TA, e.g., the UE-satellite Round Trip Time (RTT) is left to the UE to autonomously calculate. To do this, the UE has to obtain its own location and the satellite position. The UE can obtain its own location e.g., using Global Navigation Satellite System (GNSS) measurements, and the satellite’s position and/or the velocity may be derived from the ephemeris data broadcast by the gNB (in the same SIB as the Common TA parameters). The ephemeris data and the Common TA parameters are nominally valid at a so-called epoch time, which is also indicated in the same SIB (or, if the epoch time indication is absent in the SIB, the epoch time is assumed to be the end of the SI window in which the SIB was received). Based on the ephemeris data, the UE can predict the satellite’s position a certain time into the future, and the first and second time derivatives (e.g., the drift and drift variation parameters) of the Common TA may allow the UE to calculate how the Common TA value changes with time. Furthermore, the broadcast ephemeris data and Common TA parameters have a limited validity time, which is also indicated in the same SIB. The ephemeris data and Common TA parameters the UE uses when calculating the UE specific TA have to be valid, e.g., their validity time should not have expired. The same goes for the UE location information, typically based on a GNSS measurement, the UE uses in the TA calculation (in particular to calculate the UE-satellite RTT). [0111] Due to the special operating conditions in a Non-Terrestrial Network, the system information broadcasted in an NTN cell has to include NTN-specific information. To serve this purpose, a new SIB (SIB19) is introduced in NR NTN which contains NTN-specific information. In IoT NTN, the new SIB31 corresponds to SIB19 in NR NTN. [0112] In 3GPP TS 38.331 version 17.5.0 [5], SIB19 is defined as follows in ASN.1 code:

[0113] Furthermore, the NTN-Config-r17 IE is defined as follows in ASN.1 code in the same specification:

[0114] In LTE, SIB31 contains similar information for IoT NTN as SIB19 does for NR NTN. The following is the ASN.1 code for SIB31 in 3GPP TS 36.331 version 17.4.0.

[0115] SIB32, with ASN.1 code definition as follows in 3GPP TS 36.331 version 17.4.0, also contains IoT NTN specific information, which in this SIB is tailored for deployments with discontinuous coverage.

serviceInfo-r17 SEQUENCE {

longitude-r17 INTEGER (-131072..131071), latitude-r17 INTEGER (-131072..131071)

[0116] In a connected state, in the 3GPP specifications known as the RRC_CONNECTED state, the UE has an active connection to the network for sending and receiving of data and signaling. In the connected state, mobility is controlled by the network to ensure connectivity is retained to the UE with little or no interruption or noticeable degradation of the provided service as the UE moves between the cells within the network. [0117] RRC_CONNECTED state mobility comes in two main flavors: “regular” handover (reconfigurationWithSync) and conditional handover (CHO). These two handover variants are treated in the subsections below. [0118] During a “regular” handover the UE is moved from a source node using a source cell connection, to a target node using a target cell connection where the target cell connection is associated with a target cell controlled by the target node. In other words, during a handover, the UE moves from the source cell to a target cell. The source node and the target node may also be referred to as the source access node and the target access node or the source radio network node and the target radio network node. In the 5G system the source node and the target node are referred to as the source network node and the target network node. [0119] As requested by the network, a UE in RRC_CONNECTED state is required to search and perform measurements on neighbor cells both on the current carrier frequency (intra-frequency) as well as on other carrier frequencies (inter-frequency). The UE does not take any autonomous decisions when to trigger a handover to a neighbor cell (except to some extent when the UE is configured for conditional handover. Instead, the UE sends the measurement results from the measurements it performed on serving and neighboring cells to the network where a decision is taken whether to perform a handover to one of the neighbor cells. Hence, upon receiving a measurement report from the UE indicating that it may be preferable to move the UE’s RRC connection to a neighbor cell (e.g., because the measurement report indicates that the radio link in the service cell is deteriorating and/or that the radio channel quality in the neighbor cell has become (significantly) better than the radio channel quality in the serving cell), the network may send a message to the UE to instruct the UE to execute a handover. This message is an RRCReconfiguration message with a reconfigurationWithSync IE (Information Element). The message is often informally referred to as a “handover command” (although a HandoverCommand is really an inter-network RRC message which is transferred in the “Target NG-RAN node To Source NG-RAN node Transparent Container” IE in the HANDOVER REQUEST ACKNOWLEDGE XnAP message during preparation of an Xn handover and in the “Target to Source Transparent Container” IE in the Handover Request Acknowledge NGAP (NG Application Protocol, wherein the NG is the interface between NG-RAN and 5GC) message and the Handover Command NGAP message during preparation of an NG handover). [0120] In some cases, the source node and the target node are different nodes, such as different network nodes. Such a case is referred to as an inter-node or inter-network handover. In other cases, the source node and the target node are one and the same node, such as the same network node. Such a case is referred to as an intra-node or intra-network handover and covers the case when the source and target cells are controlled by the same node. In yet another case, handover is performed within the same cell and thus also within the same node controlling that cell. These cases are referred to as intra-cell handover and may be performed to refresh security parameters. [0121] It should also be understood that the source node (or source access node) and the target node (target access node) refer to a role served by a given access node during a handover of a specific UE. For example, a given network node may serve as source network node during handover of one UE, while it also serves as the target network node during handover of a different UE. And, in case of an intra-node or intra-cell handover of a given UE, the same network node serves both as the source network node and target network node for that UE. [0122] An inter-node handover in NR can further be classified as an Xn-based or NG- based handover depending on whether the source and target node communicate directly using the Xn interface or indirectly via the Core Network (through one or two Access and Mobility management Function(s) or AMF(s)) using NG interfaces. [0123] During an inter-node handover, after the handover decision has been made in the source network node, the actual handover execution is preceded by a handover preparation phase comprising communication between the source network node and the target network node. During this preparation phase, the source network node provides the target network node with state information related to the UE (referred to as the UE context), e.g., information about the UE’s PDU session resources (e.g., Quality of Service or QoS flow(s)) and various other configuration information, and the target network node performs admission control (and assumedly accepts the handover) and returns indications of the admitted PDU session resources (e.g., QoS flow(s)) and the configuration the UE should apply when accessing the target cell. The UE configuration the target network node provides is included in an inter-network RRC message called “HandoverCommand” and is formatted as an RRCReconfiguration message (including a reconfigurationWithSync IE). This RRCReconfiguration message (e.g., the handover command) is then forwarded by the source network node to the UE and this triggers the UE to execute the handover (by releasing it connection in the source cell, synchronizing with the target cell, and initiating a random access procedure in the target cell to establish a connection). In the third message of the random access procedure in the target cell the UE sends an RRCReconfigurationComplete message (often referred to as a Handover Complete message) to acknowledge the RRCReconfiguration message that triggered the handover execution and to confirm the successful execution of the handover. [0124] Figure 7 shows a flowchart illustrating an example method 700 including a series of steps to be performed between a user equipment (e.g., the UE 112 of Figure 1), a source network node (e.g., the network node 110A of Figure 1) and a target network node during an Xn-based inter-network handover in NR. In some embodiments, control plane data (e.g., RRC messages such as the measurement report, handover command and handover complete messages) are transmitted on Signaling Radio Bearers (SRBs), while the user plane data is transmitted on Data Radio Bearers (DRBs). In some embodiments, the source network node may be a network node associated with a first cell or a current cell associated with the UE. In these and other embodiments, the target network node may be a network node associated with a second cell or a new cell that the UE is transitioning to from the first cell. [0125] In some embodiments, the method 700 may start at step 701. At step 701, the UE may communicate a message to the source network node. In some embodiments, the message may include a measurement report. In some embodiments, the message may include a measurement report. At step 702, the source network node may decide to hand over the UE to the target network node, based on the message. [0126] At step 703, the source network node may send the XnAP HANDOVER REQUEST message to the target network node passing a transparent RRC container with necessary information to prepare the handover at the target side. For example, in some embodiments, the information may include the target cell id, the target security key, the current source configuration and UE capabilities. [0127] At step 704 the target network node may prepare the handover and respond with the XnAP HANDOVER REQUEST ACKNOWLEDGE message to the source network node, which may include the handover command (an RRCReconfiguration message containing the reconfigurationWithSync field) to be sent to the UE. The handover command includes configuration information that the UE should apply once it connects to the target cell, e.g., random access configuration, a new C-RNTI (Cell Radio Network Temporary Identifier) assigned by the target node, security parameters, etc. [0128] At step 705, the source network node may trigger the handover by sending the handover command (received from the target network node in the previous step) to the UE. [0129] At step 706, upon reception of the handover command, the UE may release the connection to the first (source) cell, starts the handover supervision timer T304, and starts to synchronize to the second (target) cell. [0130] At step 707, the source network node may stop scheduling any further DL user data to the UE. In some embodiments, the source network node may send the XnAP SN STATUS TRANSFER message to the target network node indicating the latest PDCP SN transmitter and receiver status. [0131] At step 708, the source network node may begin forwarding the DL user data received from the Core Network to the target network node. At step 309, the target network node may be configured to buffer the DL user data received from the source network node. [0132] At step 710, once the UE the has completed the random access procedure in the target cell, the UE stops the T304 timer and sends the handover complete message (e.g., an RRCReconfigurationComplete message) to the target network node. [0133] At step 711, upon receiving the handover complete message, the target network node may start communicating (e.g., sending and/or receiving) the user data with the UE. The target network node may request a Core Network (CN) to switch the DL user data path between the User Plane Function (UPF) and the source network node to the target network node (communication to the CN is not shown in Figure 3). In response to the path switch completing, the target network node may send the XnAP UE CONTEXT RELEASE message to the source network node to release all resources associated to the UE. [0134] Figure 8 illustrates another flowchart illustrating an example method 800 including a series of steps to be performed between a user equipment (e.g., the UE 112 of Figure 1), a source network node (e.g., the network node 110A of Figure 1) and a target network node during an Xn-based inter-network handover in NR. In some embodiments, the method 800 may be a more detailed version of the method 700 of Figure 7. For instance, the method 800 may provide additional steps that are not included in the method 700. Additionally or alternatively, the steps present in the method 700 may be broken and/or divided into multiple steps. In some embodiments, the method 800 may include additional entities performing one or more steps. For example, the method 800 may include an Access and Mobility Management Function (AMF) and a User Plane Function (UPF). [0135] In some embodiments, the method 800 may include one or more steps present in the method 700. For example, step 1 may correspond to the step 701, step 2 may correspond to the step 702; step 3 may correspond to the step 703; step 5 may correspond to the step 704; step 6 may correspond to the step 705; step 7 may correspond to the step 707; step 8 may correspond to the step 710; and step 12 may correspond to the step 711 of Figure 7. [0136] In some embodiments, the method 800 may include additional steps compared to the method 700. Particularly, the method 800 may show how the AMF and the UPF may be integrated with the method 700. For example, steps 9-11 may be related to operations of the AMF and the UPF. [0137] At step 9, the target network node may send a path switch request to the AMF. In these and other embodiments, the path switch request may indicate the need to switch the path of the UE’s session from the source network node to the target network node. [0138] At step 10, the AMF may process the path switch request and the UPF may be updated with the new network node (e.g., the target network node) information to reroute the data path. In these and other embodiments, the UPF may update internal routing tables to forward the user data to the target network node. [0139] At step 11, in response to the UPF updating the internal routing tables, the AMF may send a path switch request acknowledgement message to the target network node in response. In some embodiments, the acknowledgement message may include updated information needed for the target network node to handle the UE’s session. [0140] Figure 9A and Figure 9B are flowcharts illustrating possible instances of errors that may occur during handover process, in which conditional handovers may be applicable. For example, Figure 9A illustrates a first error flowchart 900 and Figure 9B illustrates a second error flowchart 920. In some embodiments, the flowcharts may be shown between a user equipment (e.g., the UE 112 of Figure 1) and a source network node (e.g., the network node 110A of Figure 1). [0141] In NR, handovers (or in more general terms, mobility in RRC_CONNECTED state) of UEs from a first cell to a second cell may be governed based on following principles are used for handovers. Mobility in RRC_CONNECTED state is network-controlled as the network has the best information regarding the current overall situation, such as load conditions, resources in different nodes, available frequencies, etc. The network can also take into account the situation of many UEs in the network, from a resource allocation perspective. [0142] The network prepares a target cell before the UE accesses that cell. The source network node provides the UE with the RRC configuration to be used in the target cell, including SRB1 (Signaling Radio Bearers 1) configuration for sending of the HO (Handover) complete message in the target cell. The source network node in turn receives this RRC configuration from the target network node in the form of a HandoverCommand inter-node RRC message included in the HANDOVER REQUEST ACKNOWLEDGE XnAP message (where the HandoverCommand is included in the “Target NG-RAN node To Source NG-RAN node Transparent Container” IE). [0143] In the RRC configuration provided to the UE via the source network node, the target network node configures the UE with a C-RNTI to be used in the target cell. The target network node then identifies the UE from the C-RNTI in the MAC PDU containing the RRCReconfigurationComplete message constituting the HO complete message. Hence, there is no context fetching, unless a failure occurs, since the UE context was already transferred to the target network node during the handover preparation (in the HANDOVER REQUEST XnAP message in the case of Xn handover). [0144] To speed up the handover, the network provides the UE with information on how to access the target cell, e.g., RACH (Random Access Channel) configuration, so the UE does not have to acquire System Information or SI (other than the Master Information Block or MIB) from the target cell prior to the handover. This information is included in the HandoverCommand and thus in the target cell RRC configuration sent to the UE. [0145] The UE may be provided with contention free random access (CFRA) resources (in the above mentioned RRC configuration forwarded to the UE by the source network node). The CFRA resources comprises one or more CFRA preamble(s) and may also contain CFRA occasions (e.g., Physical Random Access Channel or PRACH transmission resources that are not included in the common PRACH configuration). In that case the target network node identifies the UE from the random access preamble (Msg1). The principle is that the random access procedure can always be optimized with dedicated resources. [0146] Security is prepared before the UE accesses the target cell, e.g., when performing an inter-network handover, security keys must be refreshed before sending the HO complete message (e.g., the RRCReconfigurationComplete message), so that new keys are used to encrypt and integrity protect the HO complete message, enabling verification in the target cell. [0147] The target cell RRC configuration may be provided to the UE in two different forms: full configuration or delta configuration. In the former case, the provided RRC configuration is complete and self-contained, but a delta configuration only contains the configuration parts that are different in the target cell than in the source cell. The advantage of delta configuration is that the size of the HandoverCommand can be minimized. [0148] Handovers typically occur when the channel quality of the serving cell is degrading. The network is in control and bases the handover decision on measurement reports from the UE. In a typical case, the UE is configured to send a measurement report when an A3 event (e.g., neighbor cell quality becomes offset better than serving cell quality) is fulfilled. This will then trigger the network node to decide to pursue a handover for the UE with the target cell being selected based on the reported neighbor cell measurements. If the target cell is controlled by another network node (e.g., a neighbor gNB), the serving network node initiates the handover preparation by sending a HANDOVER REQUEST XnAP message to the neighbor network node. The neighbor network node then responds with a HANDOVER REQUEST ACKNOWLEDGE XnAP message containing, in the form of a HandoverCommand, the RRC configuration the UE should apply when connecting to the target cell. The serving (source) network node then forwards the HandoverCommand to the UE as an RRCReconfiguration message. When the UE receives this message, it releases the source cell and starts the procedure of connecting to the target cell (e.g., synchronizing with the target cell and performing random access). [0149] However, given the typical circumstances for handover, e.g., that the channel quality in the serving (source) cell is deteriorating when the UE is getting closer to the cell border, the handover operation is quite susceptible to errors. Figures 9A and 9B illustrate two such error cases, which are addressed by the Conditional Handover concept. [0150] The first error flowchart 900 of Figure 9A illustrates a first potential error associated with a regular handover. In some embodiments, the first potential error may include the measurement report not successfully reaching a source node or a source network node. For instance, at step 902, the UE may trigger an A3 event (e.g., determining that the neighbor cell is better than PCell) and generate a measurement report based on the trigger of the A3 event. At step 904, the UE may attempt a transmission of the measurement report to the source network node, such that the source network node may initiate the handover based on the measurement report. [0151] In some embodiments, the transmission of the measurement report may fail due to too many transmissions and/or reception errors. In such instances, conditions of the UE with respect to the PCell may get worse, and the UE may declare radio link failure (RLF) at step 906. The RLF may refer to a situation in which the connection between the UE and the network is lost. In some embodiments, the UE may attempt to reestablish the connection with the network. For example, the UE may scan to detect available base stations such as the source network node. [0152] In response to detecting the source network node, at step 908, the UE may send a reestablishment request to the source network node. At step 910, the connection between the UE and the source network node may be reestablished. For example, the source network node may initiate the reestablishment with the UE. For instance, the source network node may transmit information needed for the UE to connect with the source network node. At step 912, the UE may reestablish the connection with the source network node based on the information obtained from the source network node and send a reestablishment completion message to the source network node. At step 914, the source network node may reconfigure the connection with the UE. [0153] In these and other embodiments, the UE may reestablish and/or maintain connection with the source network node instead of being handed over to a target network node associated with the neighboring cell. [0154] The second error flowchart 920 illustrates a second potential error that may occur. At steps 922 and 924, the UE may generate and attempt transmission of a measurement report in response to triggering an A3 event similar to steps 902 and 904. In some embodiments, in response to obtaining the measurement report, the source network node may decide and prepare for the handover. [0155] For example, at step 925, the source network node may perform transmission of RRCReconfiguration message constituting a Handover Command to the UE. In some embodiments, the transmission may fail due to channel and/or connection quality between the UE and the source network node degrading. For instance, the connection quality may degrade faster than expected such that by the time the RRCReconfiguration message is sent, the connection is not strong enough to transmit the message. [0156] In some embodiments, steps 926, 928, 930, 932, and 934 may respectively correspond to steps 906, 908, 910, 912, and 914. For example, the steps 926, 928, 930, 932, and 934 may perform the same operations as the corresponding steps as described above. [0157] In some embodiments, to reduce or eliminate such errors as illustrated in Figures 9A and 9B, a special variant of handover called Conditional Handover (CHO) was introduced in 3GPP release 16. [0158] For example, Figures 10 and 11 illustrate message diagrams for an inter-network Conditional Handover, in accordance with some embodiments of the present disclosure. In some embodiments, Figure 10 may illustrate a diagram 1000 illustrating operations and messages transmitted between a UE 1002, a source network node 1004 associated with a first cell (e.g., a serving cell), and a target network node 1006, associated with a second cell (e.g., a candidate target cell). In some embodiments, the source network node 1004 may be referred to as a serving network node. In some embodiments, Figure 10 may show a simplified message diagram for an inter-network Conditional Handover. [0159] In some embodiments, the CHO may allow the source network node 1004 to configure the UE to autonomously trigger handover execution to a candidate target cell, when a handover execution condition (or trigger condition) configured by the serving network node 1004 is fulfilled. To realize this feature, the serving network node 1004 may include a handover execution condition – often referred to as a CHO execution condition – together with the Handover Command (which may be referred to as a Conditional Handover Command) forwarded from the target network node 1006 controlling the candidate target cell. This is configured in the condExecutionCond-r16 IE in the ASN.1 code in the RRC specification 3GPP TS 38.331 version 17.5.0. [0160] Release 16 of the 3GPP standards supports configuration of two triggering events, which in the context of CHO are referred to as conditional events (CondEvents). The supported CondEvents are CondEvent A3 and CondEvent A5 which are reused from the A3 and A5 events of the RRM framework. When used as CondEvents, A3 is defined as “Conditional reconfiguration candidate becomes amount of offset better than PCell/PSCell” and A5 is defined as “PCell/PSCell becomes worse than absolute threshold1 AND Conditional reconfiguration candidate becomes better than another absolute threshold2”. Furthermore, the specification also allows the combination of two events, whose conditions both have to be fulfilled for the duration of the configured time-to-trigger period, in order for the CHO execution to be triggered. [0161] In some embodiments, the CHO may be applicable for both intra-network handover and inter-network handover. Figure 10 may illustrate a feature in the inter-network CHO case, as the inter-network handover may be the most comprehensive and challenging case which best illustrates the complete concept. [0162] In some embodiments, in response to receiving the RRCReconfiguration message including configuration of a CHO (e.g., including a Handover Command and an associated CHO execution condition), the UE 1002 may not initiate execution of the handover immediately. Instead, the UE 1002 remains connected to the serving cell and begins to monitor the configured CHO execution condition (for the indicated candidate target cell). In these and other embodiments, a cell associated with a conditional handover configuration (e.g., a cell which the UE 1002 may connect to if the CHO execution condition is fulfilled) may be referred to as a candidate target cell. Similarly, a network node controlling a cell associated with a conditional handover configuration (e.g., a candidate target cell) may be referred to as a candidate target network node (e.g., the target network node 1006). [0163] The UE 1002 may be configured with multiple candidate target cells. For each candidate target cell, the UE 1002 is provided with an associated Handover Command (e.g., an RRCReconfiguration to be applied if/when connecting to the candidate target cell) and an associated CHO execution condition. [0164] In some instances, in which the CHO execution condition is fulfilled for a candidate target cell, the UE 1002 may release the source cell and start executing the handover towards the candidate target cell (which then becomes the target cell) for which the associated CHO execution condition was fulfilled. From the UE’s point of view, the rest of the procedure proceeds like a regular handover procedure, except that the UE 1002 discards all CHO configurations when it has successfully connected to the target cell. [0165] On the network side, the serving/source network node 1004 may not be aware of if or when a CHO execution condition is fulfilled for the UE 1002. For example, the UE 1002 may release the source cell without informing the source network node 604. In these and other embodiments, after handover completion, (e.g., after successful random access and successful reception of the RRCReconfigurationComplete message or a Handover Complete message), the target network node 1006 may send a HANDOVER SUCCESS XnAP message to the source network node 1004. This informs the source network node 1004 that the UE 1002 has left the source cell and successfully completed a handover to the target cell controlled by the target network node 1006. If multiple candidate target network nodes were prepared for CHO for the UE 1002, the source network node 1004 can cancel the CHO preparations in the other (non-selected) candidate target network nodes using the HANDOVER CANCEL XnAP message, so that these network nodes can release any reserved resources. [0166] During a regular handover, the source network node 1004 may start to forward user plane data arriving in the source network node 1004 to the target network node 1006 (for further forwarding to the UE 1002) as soon as the Handover Command is sent to the UE 1002. In CHO, however, due to the uncertainty of if and when the UE 1002 will actually execute a handover, it may be suboptimal to start forwarding user plane data to a candidate target network node upon transmission of the Handover Command, since this may cause unnecessary load on the Xn user plane, as well as processing load in the candidate target network node. Therefore, the source network node 1004 can choose not to initiate user plane forwarding until it receives the HANDOVER SUCCESS XnAP message from the target network node. On the other hand, not initiating user plane forwarding until the HANDOVER SUCCESS XnAP message is received delays the availability of buffered downlink data in the target network node, which increases the handover interruption time. Therefore, both options are available for CHO, referred to as early data forwarding (triggered any time after transmission of the Handover Command and before reception of the HANDOVER SUCCESS XnAP message) and late data forwarding (triggered upon reception of the HANDOVER SUCCESS XnAP message). [0167] In some embodiments, the RRCReconfiguration* indicated with an asterisk (‘*’) is the Handover Command containing the RRC reconfiguration the UE 1002 shall apply if/when connecting to the candidate target network node 1006 in the selected target cell. [0168] In some embodiments, Figure 11 may illustrate a diagram 1100 illustrating operations and messages transmitted between a UE 1102, a source network node 1104 associated with a first cell (e.g., a serving cell), and a target network node 1106, associated with a second cell (e.g., a candidate target cell), other potential target network node(s) 708, an APF 1110, and UPF(s) 1112. In some embodiments, the diagram 1100 may be substantially similar to the diagram 1000 of Figure 10. For example, the UE 1102 may correspond to the UE 1002, the source network node 1104 may correspond to the source network node 1004, and the target network node 1106 may correspond to the target network node 1006. In these and other embodiments, the diagram 1100 may differ from the diagram 1000 with respect to the other potential target network node(s) 1108, the AMF 1110, and the UPF(s) 1112. In some embodiments, a gNB may be referred to as a network node. For example, the source network node 1104 may be referred to as a source node, and the target network node 1106 may be referred to as a target node. [0169] Figure 11 shows an Inter-network Conditional Handover message flow in NR. The RRCReconfiguration message in step 6 is the Handover Command containing the CHO configuration(s). The message diagram is copied from 3GPP TS 38.300 version 16.8.0. [0170] Based on, for example, a measurement report received from the UE 1102 (in a MeasurementReport RRC message), the source node decides to configure the UE 1102 for CHO (step 2 in Figure 11). [0171] The source node prepares one or potentially more candidate target nodes by including a CHO indicator and the current UE configuration in the HANDOVER REQUEST XnAP message sent over Xn (step 3). Unlike a regular (non-CHO) handover, CHO enables the network to prepare the UE 1102 with more than one candidate target cell, each candidate target cell with its own target cell configuration (RRCReconfiguration) and its own CHO execution condition. The target cell configuration is generated by the candidate target node 706 while the CHO execution condition is configured by the source node 1104. For CHO in 3GPP Release 16, the CHO execution condition may comprise one or two trigger conditions – the A3 and A5 signal strength/quality-based events as defined in 3GPP TS 38.331 version 16.7.0. [0172] As in a regular (non-CHO) handover, the handover command (RRCReconfiguration message) sent to the UE 1102 in step 6 is generated by the candidate target node 1106 but transmitted to the UE 1102 in the source cell by the source node 1104. In case of an inter-node handover (as in Figure 11), the handover command is sent from the candidate target node 1106 to the source node 1104 within the HANDOVER REQUEST ACKNOWLEDGE XnAP message (step 5) as a transparent container (specified as the HandoverCommand inter-node RRC message in 3GPP TS 38.331 version 17.5.0 [Reference 5]), meaning that the source node 1104 does not change the content of the handover command. [0173] The target cell configuration (the RRCReconfiguration for the UE to use in the candidate target cell) and the CHO execution condition for each candidate target cell provided by the network to the UE 1102 may collectively be referred to as a CHO configuration, or, alternatively, each combination of candidate target cell, target cell configuration and CHO execution condition may be referred to as a CHO configuration (e.g., the terminology is not consistent). When received by the UE 1102 in the handover command (RRCReconfiguration message in step 6), the target cell configuration is not applied immediately as in a regular (non- CHO) handover. Instead, the UE 1102 may start to evaluate the CHO execution condition(s) configured by the network. [0174] The network may configure the UE 1102 with one or two trigger conditions (A3 and/or A5 event) per CHO execution condition and candidate target cell. If the UE 1102 is configured with two trigger conditions, then both events need to be fulfilled to trigger the UE 1102 to execute the CHO towards the candidate target cell. [0175] When the CHO execution condition is fulfilled for one of the candidate target cells, the UE 1102 may release its source cell connection, applies the associated target cell configuration (RRCReconfiguration), and starts the handover supervision timer T304. The UE now connects to the target node as in a regular handover (step 8). Any CHO configuration stored in the UE is released after completion of the (conditional) handover procedure. [0176] In some embodiments, the target node 1106 may send the HANDOVER SUCCESS XnAP message over Xn to the source node 1104 to inform the source node 1104 that the UE 1102 has successfully accessed the target cell (step 8a). Triggering of data forwarding to the target node 1106 may typically be performed after receiving the HANDOVER SUCCESS XnAP message in the source node 1104 – this is also known as “late data forwarding”. As an alternative, data forwarding may be triggered at an earlier stage in the handover procedure, after receiving the RRCReconfigurationComplete message from the UE (step 7). This mechanism is also known as “early data forwarding”. [0177] If more than one candidate target cell was configured during the Handover Preparation phase, then the source node 1104 needs to cancel the CHO for the candidate target cells not selected by the UE 1102. The source node 1104 may send the HANDOVER CANCEL XnAP message over Xn on the other signaling connection(s) and/or the other candidate target node(s) 1108 to cancel the CHO and thus to initiate a release of the reserved resources in the target node(s) (step 8c). [0178] During a regular (non-CHO) handover, if the handover attempt fails due to e.g., a radio link failure or expiry of timer T304, the UE 1102 will typically perform a cell selection and continue with an RRC re-establishment procedure. But when a CHO execution attempt fails and the selected cell happens to be a candidate target cell included in the CHO configuration, the UE 1102 may instead attempt a CHO execution to the selected cell. This UE 1102 behavior is however enabled/disabled by means of network configuration. [0179] In the ASN.1 code in the RRC specification 3GPP TS 38.331 version 17.5.0, the CHO configurations are provided to a UE in the form of an add-mod-list (a ToAddModList denoted as CondReconfigToAddModList-r16). That is, a list of CHO configurations to be added to the CHO configurations the UE 1102 has previously received and stored, or to replace/modify CHO configurations the UE 1102 has previously received and stored. The UE 1102 stores the CHO configurations in the “UE variable” VarConditionalReconfig. In these and other embodiments, the UE 1102 is not mandated to implement a UE variable exactly as specified. A UE variable is a tool used in the specification to clearly describe the expected behavior or outcome of certain specified actions, e.g., configuration actions. The add-mod-list containing CHO configurations (e.g., CondReconfigToAddModList-r16) is included in an IE called ConditionalReconfiguration, which in turn is included in an RRCReconfiguration message. The relevant ASN.1 code from 3GPP TS 38.331 version 17.5.0 is included below. [0180] RRCReconfiguration message [0181] ConditionalReconfiguration information element

[0182] CondReconfigToAddModList information element

[0183] As can be seen from the ASN.1 code above, the condRRCReconfig-r16 IE contains an RRCReconfiguration. This is the RRCReconfiguration the UE should apply in the candidate target cell towards which the CHO is executed, if and when the CHO execution condition indicated by the condExecutionCond-r16 IE is fulfilled for the candidate target cell (e.g., this RRCReconfiguration constitutes the Conditional Handover Command). [0184] An additional remark is that recursive CHO configurations are precluded by the release 17 3GPP standard. More precisely, a ConditionalReconfiguration-r16 IE cannot be included in an RRCReconfiguration message which contains a masterCellGroup IE for which the CellGroupConfig (which is included in the masterCellGroup IE as an OCTET STRING) contains a ReconfigurationWithSync IE. Hence, a Handover Command or a Conditional Handover Command cannot contain a ConditionalReconfiguration-r16 IE. This is clear from the following field description for the conditionalReconfiguration-r16 field in the RRCReconfiguration message (copied from 3GPP TS 38.331 version 17.5.0):

[0185] Two of the challenges related to NTN support for CHO are frequent and unavoidable handovers (e.g., due to feeder link switch or cell switch in a quasi-Earth-fixed cell deployment) and handover of a large number of UEs, both of which can result in significant control plane overhead and frequent service interruptions. This issue is perhaps most pronounced in the quasi-Earth-fixed cell scenario when a geographic area is covered by a satellite (serving a cell covering the geographic area) for a limited time period while being replaced by a new satellite (serving a new cell covering the same geographic area) during the next time period, and so on. When the satellite covering the geographic area is replaced, the cell is also replaced, meaning that all the UEs connected in the old cell have to be handed over to the new cell, which potentially results in a high control signaling peak, because all the handovers have to occur in conjunction with the cell replacement (a.k.a. cell switch). [0186] Hard and soft cell switch have been discussed in 3GPP, with preference for the soft switch case, wherein the old and the new cell both (simultaneously) cover the geographic area during a short overlap period, to simplify handovers with low interruptions. [0187] To mitigate the expected signaling overhead at frequent handovers for a large number of UEs, 3GPP agreed to introduce support for Conditional Handover (CHO) for NTN in 3GPP release 17 with the CHO procedure and the trigger conditions as defined for NR in 3GPP release 16 as a baseline. [0188] In terrestrial networks, a UE can typically determine that it is near a cell edge by detecting a clear difference in the received signal strength (e.g., by performing RSRP-based measurements) compared to the received signal strength at the cell center. In NTN deployments on the other hand, the difference in signal strength between the cell center and the cell edge is typically smaller. That is, the signal strength decreases slowly with the distance from the cell center (much smaller than in a typical terrestrial cell). This is often described as a “flat signal strength” or a “flat RSRP”. Thus, a UE may experience a small difference in signal strength between two beams (e.g., representing two cells) in a region of overlap. This may lead to suboptimal UE behaviors such as repetitive handovers (“ping-pong handovers”) back and forth between the two cells. [0189] To avoid an overall reduction in handover robustness, 3GPP agreed to introduce the following trigger conditions (apart from the already existing trigger conditions, the A3 and A5 CondEvents) for CHO in NTN: a new time-based trigger condition (CondEvent T1), defining a time period, or a time window, when the UE may execute CHO to a candidate target cell; a new location-based trigger condition (CondEvent D1), defining a first distance threshold for the distance from the UE to a reference location in the source cell and a second distance threshold for the distance from the UE to a reference location in a candidate target cell, based on which the UE may trigger and execute CHO; and reuse of the existing A4 event in the form of CondEvent A4 (“conditional reconfiguration candidate becomes better than absolute threshold”) as defined in 3GPP TS 38.331 version 17.5.0. [0190] The time-based trigger condition is defined by 3GPP as the time period [T1, T2] associated with each candidate target cell, where T1 is the starting point of the time period represented by a Coordinated Universal Time (UTC) and T2 is the end point of the time period represented by a time duration elapsing after T1. [0191] The time-based trigger condition (condEventT1-r17) is defined in ASN.1 in the ReportConfigNR IE in 3GPP TS 38.331 version 17.5.0 as shown below:

[0192] The duration encoded by the duration-r17 field should be counted as starting from T1, which means that in principle T2 = T1 + duration = t1-Threshold-r17 + duration-r17. [0193] In 3GPP Specification TS 38.331 version 17.5.0, T1 is represented in ASN.1 by the field t1-Threshold-r17, which is an INTEGER encoding a UTC in terms of the number of 10 ms units that have elapsed since 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, 1899 and Monday, January 1, 1900). Each step of the duration-r17 field (e.g., the different duration values) represent 100 milliseconds. The value range of the duration-r17 field is thus 100 milliseconds up to 600 seconds. [0194] In some examples, the time-based trigger condition (and the location-based trigger condition) can only be configured to the UE in combination with one of the signal strength/quality based CondEvents A3, A4 or A5 (which are repurposed versions of the A3, A4 and A5 events which are used as triggering events for measurement reporting). For the time-based trigger condition this implies that the UE may only perform CHO to the candidate target cell in the time window defined by T1 and T2 if the signal strength/quality-based event is fulfilled within this time frame. The time-based condition AND the signal strength/quality- based condition must thus be fulfilled simultaneously in order for the UE to execute the CHO. [0195] If the CHO execution for a certain candidate target cell is not triggered during the time period [T1, T2], e.g., after T1 but before T2, or if the CHO execution is triggered during this time period, but the CHO execution fails, the UE is not allowed to use the CHO configuration after T2, even if it in the cell selection during a triggered RRC re-establishment procedure happens to select the concerned candidate target cell and even if the network configuration allows the UE (by including the attemptCondReconfig field in the ConditionalReconfiguration IE) to perform conditional reconfiguration to a candidate target cell. This rule applies also if the UE selects another cell for which the UE has a CHO configuration, e.g., if time has passed T2 for that CHO configuration, the UE is not allowed to use the CHO configuration to turn the RRC re-establishment into a CHO execution for that cell. [0196] In addition to the time-based condition, a location-based condition for CHO execution (CondEvent D1) is also specified. The location-based condition is fulfilled if the UE’s distance to a reference location of the serving (source) cell (assumedly representing the center of the serving/source cell) exceeds a first threshold while the distance to a reference location of a candidate target cell (assumedly representing the center of the candidate target cell) goes below a second threshold. Like the time-based condition, the location-based condition must be combined with one of the signal strength/quality-based CondEvents A3, A4 or A5, and both the location-based condition and the signal strength/quality-based condition have to be fulfilled for the CHO execution to be triggered. [0197] In some examples, satellite switches and feeder link switches in quasi-Earth-fixed cells deployment (see, e.g., paragraphs [0083]-[0100] herein) can be realized with unchanged carrier frequency and unchanged PCI. Primarily, the working assumption concerns so-called hard switch, e.g., where the pre-switch conditions and the post-switch conditions for the cell area coverage do not exist in parallel during a transition period, but instead the cell area’s coverage according to the post-switch conditions begins (ideally) momentarily when the cell area’s coverage according to the post-switch conditions end (cease to exist). In some examples, the unchanged PCI and carrier frequency principle can be used also for so-called soft switch, e.g., where the cell area is covered both according to pre-switch conditions and according to post-switch conditions (e.g., the old and the new serving satellite or the old and the new feeder links are used simultaneously, e.g., in parallel) during a transient coexistence period (also referred to as overlap period). [0198] The fact that the carrier frequency and PCI remains unchanged after the cell switch makes it look (from the UE’s point of view) as the same cell, e.g., the UE will perceive it as the same cell before and after the cell switch (assuming that the carrier frequency and the PCI – at least locally – defines the cell). Because of this circumstance, it is questionable if this kind of switch should be referred to as a cell switch. Still, for convenience and simplification of the description, the type of switch may also be referred to as a cell switch, and the pre-switch conditions may be referred to as the old cell (or sometimes the source cell or first cell) and the post-switch conditions may be referred to as the new cell (or sometimes the target cell or second cell). [0199] The general assumption is that in such a scenario, a UE in RRC_CONNECTED state can be moved from the old cell to the new cell without Layer 3 (L3) mobility, and that the UE should only have to synchronize with the new cell to execute the UE’s switch from the old cell to the new cell. [0200] In an instance, a UE may be RRC configured to be prepared for upcoming switch of RAN (e.g., sat-gateway). The configuration may include one or more of the following parameters: the time when the RAN switch will happen (Time may be expressed as a common time reference between RAN and UEs, such as an absolute time (e.g., GPS time, UTC time) or a common reference in relation to system frame number (SFN) in the radio frames. This may include when the DL RS is switched off and/or switch ON); indication if PCI will change or not, with/without new PCI that will take over (That is, if after RAN switch the same PCI will be sent from the satellite taking over the geographical area or if it is different PCI); indication of change in system information; indication of switch of any RAN identification; indication of change of TA assumption; indication of change of downlink frequency; indication of change of uplink frequency adjustment assumption; UE may be indicated to start connected mode DRX while the cell switch happens; and/or indication of when the configuration becomes valid, possibly including: time or timer; and switch to other RRC configuration may happen when primary or secondary cell is at a configured elevation angle. [0201] In these instances, the UE may be configured to send a response to the RRC configuration according to follows: confirmation at reception of RRC configuration; confirmation at application of configuration as there may be a condition when the configuration becomes valid; and failed application of configuration. [0202] There currently exist certain challenge(s). In particular, the concept of cell switches with unchanged carrier frequency and PCI is immature and still lacks many of the detailed mechanisms needed to make it work. These voids are problematic and need to be addressed, and this is what the solution proposed herein aims to do. [0203] Certain aspects of the present disclosure and embodiments herein may provide improvements to the above stated problems. The main aspects of the proposed solution may relate to assistance information the network may provide to a UE prior to a cell switch with unchanged carrier frequency and PCI in order to facilitate for the UE to handle the cell switch in an efficient way. Various types of assistance information are proposed, as well as means for signaling the assistance information to the UE(s). [0204] Other embodiments focus on aspects of the UE’s execution of the cell switch and the network’s execution of the cell switch, to a large extent involving usage or provision of the assistance information. [0205] The present disclosure may be generally described for the hard switch scenarios but may also be applicable in soft switch scenarios which may be discussed with further detail in the present disclosure. [0206] Certain embodiments may provide one or more of the following technical advantage(s). The proposed solution fills the current voids of the concept of cell switches with unchanged carrier frequency and PCI. [0207] Figures 12 and 13 are flowcharts illustrating methods for performing cell switch by a UE and a network node, respectively. Figures 12 and 13 provide an overview of the methods for performing cell switch. Detailed descriptions and examples are provided after providing the overview using Figures 12 and 13. Figure 12 illustrates a flow chart of an example method 1200 for performing a cell switch, arranged in accordance with at least one embodiment of the present disclosure. One or more operations of the method 1200 may be implemented by a user equipment (UE) such as the UE 112 of Figure 1 and/or device 508 of Figure 5. Although illustrated as discrete steps, various steps of the method 1200 may be divided into additional steps, combined into fewer steps, or eliminated, depending on the desired implementation. Additionally, the order of performance of the different steps may vary depending on the desired implementation. [0208] In some embodiments, the method 1200 may start at block 1202. At block 1202, the UE may receive, from a network node, cell-switching assistance information for performing the cell switch with unchanged physical cell identity (PCI). [0209] At block 1204, the UE may determine a timing advance (TA) for the UE to use after the cell switch based on ephemeris parameters and common timing advance parameters of the second cell (e.g., the new cell after the cell switch). In these and other embodiments, the TA may be accurate enough for the UE to transmit (e.g., on the PUCCH or the PUSCH), but the UE may also optionally perform a random access in the new cell to get its TA adjusted by the network. [0210] At block 1206, the UE may be configured to report the TA to the network using the Timing Advance Report MAC (Medium Access Control) CE (Control Element). At block 1208, the UE may then receive a UE specific K_offset parameter value in a Differential K_offset MAC CE from the network (which may indicate the difference between the cell specific K_offset (which is configured by the cellSpecificKoffset-r17 IE in the NTN-Config- r17 IE, and which thus may be part of the assistance information) and the UE specific offset). [0211] At block 1210, the UE may perform the cell switch from a first cell to a second cell based on the cell-switching information. In some embodiments, the first cell and the second cell may be associated with a first satellite and a second satellite, respectively. In some embodiments, the first satellite and the second satellite may be a same satellite. In other embodiments, the first satellite and the second satellite may be different. [0212] Modifications, additions, or omissions may be made to the method 1200 without departing from the scope of the present disclosure. For example, one skilled in the art will appreciate that, for this and other processes, operations, and methods disclosed herein, the functions and/or operations performed may be implemented in differing order. Furthermore, the outlined functions and operations are only provided as examples, and some of the functions and operations may be optional, combined into fewer functions and operations, or expanded into additional functions and operations without detracting from the essence of the disclosed embodiments. [0213] Figure 13 illustrates a flow chart of an example method 1300 for performing a cell switch, arranged in accordance with at least one embodiment of the present disclosure. One or more operations of the method 1300 may be implemented by a network node such as the network node 110 of Figure 1, station 506 of Figure 5, and/or the source network node 1104 of Figure 11. Although illustrated as discrete steps, various steps of the method 1300 may be divided into additional steps, combined into fewer steps, or eliminated, depending on the desired implementation. Additionally, the order of performance of the different steps may vary depending on the desired implementation. [0214] In some embodiments, the method 1300 may start at block 1302. At block 1302, the network node may send cell-switching assistance information to the UE, wherein the cell switch is based on the cell-switching assistance information with unchanged physical cell identity (PCI). [0215] At block 1304, the network node may receive, from the UE, a timing advance for the UE to use after the cell switch. At block 1306, the network node may determine a UE- specific K_offset parameter value to use after the cell switch based on the timing advance. [0216] At block 1308, the network node may send to the UE, the UE-specific K_offset parameter value to use after the cell switch. [0217] Modifications, additions, or omissions may be made to the methods 1300 without departing from the scope of the present disclosure. For example, one skilled in the art will appreciate that, for this and other processes, operations, and methods disclosed herein, the functions and/or operations performed may be implemented in differing order. Furthermore, the outlined functions and operations are only provided as examples, and some of the functions and operations may be optional, combined into fewer functions and operations, or expanded into additional functions and operations without detracting from the essence of the disclosed embodiments. [0218] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. [0219] In this disclosure, the concept of ‘network’ and/or a gNB can be understood as a generic network node, a gNB, a base station, a unit within the base station to handle at least some operations, a relay node, a core network node, a core network node that handles at least some operations, or a device supporting Device to Device (D2D) communication. The network node may be deployed in a 5G network, or a 6G network. [0220] In some embodiments, the network node (e.g., the source network node 1004 of Figure 10), may facilitate for the UE to handle the cell switch by providing assistance information or configuration information to the UE. [0221] For example, with reference back to Figure 12, as described above, in block 1202 of method 1200, UE may receive the cell-switching assistance information including one or more of: information related to satellite orbit and feeder link propagation delay related to the second satellite, during and/or after the cell switch; information related to timing of synchronization signal block (SSB) transmissions from the second satellite during and/or after the cell switch; and/or information related to transmission configuration indicator (TCI) states including satellite information associated with the second satellite. [0222] In these and other embodiments, the satellite information included in the TCI states may be used to indicate whether the TCI configuration is associated with a first satellite (e.g., a current or old satellite) or the second satellite (e.g., a new satellite). For example, in instances in which there are multiple SSBs per cell, there may be either intra-satellite SSB change or inter-satellite SSB change. For hard cell switch with unchanged PCI and carrier frequency, the UE behavior may be different for intra-satellite SSB change and inter-satellite SSB change, e.g., for intra-satellite SSB change the UE may/can/shall change to the new SSB immediately, while for inter-satellite SSB change the UE may/can/shall change to the new SSB only after the new satellite appears (e.g., when the new cell, which is served by the new satellite, appears). To facilitate this, the satellite information (e.g., part of the assistance information can be added in the TCI configuration, e.g., added in the QCL-Info IE in the TCI-State IE. This info can be a satellite identifier or just a simple indicator (e.g., one bit) to indicate whether the TCI-state is related to the current serving satellite or a new satellite that appears in the future. When receiving a DCI message indicating the TCI that the UE shall apply, if the TCI is related a new satellite that appears in the future, the UE applies the TCI (e.g., switches to the SSB of the new satellite) after the UE switches to the new satellite based on the received assistance information. [0223] These considerations may be particularly relevant if the cell switch is specified/implemented with L1/L2 triggered mobility (LTM) as the baseline. [0224] Additionally or alternatively, the cell-switching assistance information may include one or more of: information related to timing of the cell switch; information related to general properties of the cell switch, the information related to the general properties of the cell switch including one or more of: PCI of the second cell, or an indication of a type of the cell switch. [0225] In some embodiments, the type of the cell switch is a first type or a second type, wherein the first type includes cell switches without a period of overlap between the first cell and the second cell, and the second type includes cell switches with at least a partial period of overlap between the first cell and the second cell. In some embodiments, the first type may be a hard switch and the second type may be a soft switch. [0226] In some embodiments, the information related to the timing of the cell switch may include information related to appearance of the second cell. Additionally or alternatively, the information related to the timing of the cell switch may include a gap length representing time between disappearance of the first cell and appearance of the second cell. [0227] Additionally or alternatively, the cell-switching assistance information may include one or more of: information related to a difference in timing between the first cell and the second cell; information related to location and coverage of the second cell; and/or information related to provision or transfer of the cell-switching assistance information or configuration information to the UE. [0228] In some embodiments, the information related to the satellite orbit and the feeder link propagation delay related to the second satellite, during and/or after the cell switch comprises one or more of: ephemeris parameters of the second satellite during and/or after the cell switch; or common timing advance (TA) parameters related to the second satellite. [0229] To execute the cell switch, the UE makes use of any assistance information it may have received, and in particular, the UE applies the NTN-Config-r17 information for the new cell (e.g., the cell after the cell switch) and restarts the validity timer associated with the ephemeris and Common TA parameters (which is configured by the ntn- UlSyncValidityDuration-r17 IE), e.g., timer T430, with respect to the epoch time associated with the ephemeris and Common TA parameters. The UE may use the obtained ephemeris and Common TA parameters to (together with the information about the UE’s location) determine the UE’s timing advance (TA) to be used after the cell switch. [0230] If needed, the UE would then obtain DL synchronization in the new cell (e.g., after the cell switch) by receiving PSS and SSS, e.g., by receiving an SSB transmission. [0231] If not already provided before the cell switch, or if it remains the same after the cell switch as before the cell switch, the UE should acquire SIB19 after the cell switch to collect any remaining relevant information. [0232] In some embodiments, the system information may be the most advantageous means to convey this information to the UEs in the cell, but any other suitable signaling means may be used. The assistance information may be, for example, sent as an extension of SIB19 or as an entirely new SIB. In either case, the broadcasted information can be utilized by UEs in all RRC states (e.g., RRC_CONNECTED state, RRC_INACTIVE state and RRC_IDLE state). [0233] Some basic information that may be sent to a UE as part of the assistance information may be information related to the nature of the upcoming switch. For example, the information may include whether the cell switch is hard or soft, whether the PCI and carrier frequency remains the same after the cell switch, and when the cell switch will occur (e.g., an indication of when the new cell (or the new conditions of the same cell) will appear). [0234] Furthermore, the network node that serves the first cell before the cell switch may include in the assistance information, information that allows a UE to proactively determine essential parameters to be used after the cell switch, such as the service link delay, the feeder link delay, the TA to use, and the UE-gNB RTT. This information may include the ephemeris and Common TA parameters of the new cell (e.g., the cell after the cell switch), and also the K_mac parameter associated with the cell after the cell switch. [0235] The information about the time of the cell switch may be made more elaborate, more generic and providing richer information. One way to achieve this is to provide the cell switch time related information in the form of a “gap length” indication, where the gap is the time between the disappearance of the old cell (e.g., the pre-switch conditions) and the appearance of the new cell (e.g., the post-switch conditions) (and note that this gap length may be negative). The gap length indication can be captured in the ASN.1 of the RRC protocol specification e.g., as a “CellSwitchGap-rXX” IE, and the new cell would appear at the time equal to the time of disappearance of the old cell plus CellSwitchGap-rXX (e.g., equal to t- Service-r17 (of the old cell) + CellSwitchGap-rXX, assuming that t-Service-r17 indicates the time when the old cell disappears). The CellSwitchGap-rXX” IE can be an integer (e.g., the INTEGER ASN.1 type), e.g., expressing the time gap in units of 1 ms or 100 µs. CellSwitchGap-rXX = 0 would mean a perfect hard switch. CellSwitchGap-rXX < 0 would mean cell switch with overlap/coexistence of the old and the new cell (e.g., a soft switch). CellSwitchGap-rXX > 0 would mean discontinuous coverage (e.g., there is a non-zero duration between the disappearance of the old cell and the appearance of the new cell during which there is no coverage, e.g., no service, from any of the two cells). The CellSwitchGap-rXX IE can thus cover a range of quasi-Earth-fixed cells deployment scenarios. [0236] In some embodiments, the assistance information may include information about the timing difference between the first cell (e.g., the old cell) and the second cell (e.g., the new cell) in terms of frame borders, subframe borders, slot borders and symbol borders. The timing difference can be indicated with the respective gNB (which may be different the same before and after the cell switch) as reference points, or with the respective satellite (which may be different or the same before and after the cell switch) as the reference points, or the reference points can be the uplink/downlink alignment reference point (also referred to as the uplink time synchronization reference point) before and after the cell switch. New parameters may be specified for this purpose, but it would also be possible to reuse, or be inspired by, existing parameters related to “SFN and frame timing difference” (SFTD) framework, e.g., the MeasResultCellSFTD-NR IE or the sfn-OffsetResult and/or frameBoundaryOffsetResult field in the MeasResultCellSFTD-NR IE. Receiving this information prior to the cell switch would facilitate for the UE to determine the downlink timing/synchronization and/or the uplink timing/synchronization after the cell switch. [0237] Other information that can be included in the assistance information includes information related to the SSB (Synchronization Signal Block) transmissions after the cell switch, in particular the timing of the SSB transmissions. Such information can be provided in the form of an SMTC (SSB Measurement Timing Configuration), e.g., using (as one option) the cell timing before the cell switch as the reference, or (as another option) using the cell timing after the cell switch as the reference (provided that the UE has been informed of the timing difference between the new cell and the old cell, e.g., after and before the cell switch). However, the time window of an SMTC has a 1 ms granularity, while the network is aware of this timing with better accuracy than 1 ms. Hence, the information about when SSBs are transmitted, e.g., when an SS burst (which may consist of one or more SSBs) is transmitted, can include timing indications with better accuracy then what is feasible with a time window in an SMTC. For instance, such more accurate information can include an indication of when SS bursts are transmitted after the cell switch, e.g., with microsecond accuracy for the start of the SS burst, optionally complemented by an SS burst duration and an SS burst periodicity indication. [0238] Another way would be to rely on the previously described indication of the difference in timing between the new and the old cell (e.g., the difference in the cell timing between after and before the cell switch), expressed e.g., in terms of difference in SFN (System Frame Number) and frame (and/or slot and/or symbol) border timing, or, in case it can be assumed that the SFNs keeps running across the cell switch, only the difference in frame (and/or slot and/or symbol) border timing. This timing difference indication can then be complemented with an indication of in which SFNs, slots and, if needed, symbols the SSBs or SS bursts are transmitted. And in case the SSBs, or SS bursts, are transmitted in the same SFNs, slots and symbols after the cell switch as before the cell switch, the indication of the difference in timing is all that is needed. One possibility is to allow an optional indication of the SFNs, slots and symbols the SSBs, or SS bursts, will be transmitted after the cell switch, and in case of absence of this indication, as default the UE assumes that the SSBs, or SS bursts, are transmitted in the same SFNs, slots and symbols after the cell switch as before the cell switch. Yet another possibility is to indicate the difference in timing of when the SSBs are transmitted, e.g., in terms of the difference in timing of the transmission of the first SSB in SS bursts in the new cell compared with the old cell. [0239] In another embodiment, information related to location of the replacing satellite beam(s) forming the coverage of the cell (e.g., a location in the beam’s footprint on the ground) may be given as assistance information to the UE. In SIB19, the fields referenceLocation-r17 and distanceThresh-r17 are provided as follows:

[0240] In the above table, “distanceThresh” denotes the distance from the serving cell reference location and is used in location-based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. Each step represents 50 m. [0241] The “referenceLocation” denotes the reference location of the serving cell provided via NTN quasi-Earth fixed system and is used in location-based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. [0242] The new assistance information may use the same parameters but with values of the new cell/beam. In a variant, the assistance information gives ranges related to at least one of these parameters. In yet another variant, the assistance information gives relation, exact point or exact threshold or range with respect to the coverage of the old cell. [0243] Possible assistance information or configuration information may include one or more of: (1) information related to general properties of the cell switch; (2) information related to the timing of the cell switch; (3) information related to the satellite orbit and feeder link propagation delay after the cell switch; (4) information related to the difference in timing; (5) information related to the timing of the SSB transmissions after the cell switch; (6) information related to the location and coverage of the new cell; and/or (7) information related to the provision or transfer of assistance information or configuration information to the UE. [0244] In some examples, the information related to general properties of the cell switch include: an indication that the PCI (Physical Cell Identity) remains the same after the cell switch as before the cell switch, or an indication of whether the PCI remains the same after the cell switch as before the cell switch; the PCI of the cell after the cell switch (from which the UE can determine if the PCI is changed by comparing it with the PCI before the cell switch); and/or an indication of whether it is a hard switch or a soft switch. [0245] In some examples, the information related to the timing of the cell switch includes: an indication of the time when the cell switch will occur. This may be expressed in terms of e.g., any combination of one or more of an H-SFN, an SFN (System Frame Number), a subframe, a slot number, a symbol number, all according to the DL timing before the cell switch. The reference point for this time indication may e.g., be the uplink/downlink alignment reference point (also known as the uplink time synchronization reference point). This may also be expressed in terms of a UTC (Coordinated Universal Time) indication in combination with any of the above. This UTC indication may be coarse, e.g., accurate enough to make the H- SFN, SFN, subframe or slot number indication unambiguous. This may also be expressed in terms of a UTC indication. This may also be expressed in terms of the t-Service-r17 IE, that is, the t-Service-r17 field in SIB19 can be used to express when the current cell – or when the pre- switch conditions – will cease to exist, and this can coincide with the appearance of the new cell – or the post-switch conditions – e.g., the time indicated by the t-Service-r17 field prior to the cell switch would indicate the time of the cell switch (in the case of a perfect hard switch (e.g., no coexistence/overlap period and no gap between the old cell (pre-switch conditions) and the new cell (post-switch conditions). This may also be expressed in terms of a “gap length” indication, or “cell switch gap” indication, e.g., a CellSwitchGap-rXX IE (as described above), which may be combined with any of the above (e.g., the t-Service-r17 IE, any combination of one or more of an H-SFN, an SFN, a subframe, a slot number, and a symbol number, a UTC indication, a (coarse) UTC indication combined with any combination of one or more of an H- SFN, an SFN, a subframe, a slot number, and a symbol number. [0246] In some embodiments, the information related to the timing of the cell switch includes an indication of when the new cell will appear. This may be expressed in terms of e.g., any combination of one or more of an H-SFN, an SFN, a subframe, a slot number, or a symbol number, all according to the DL timing before the cell switch. The reference point for this time indication may e.g., be the uplink/downlink alignment reference point (also known as the uplink time synchronization reference point). This may also be expressed in terms of a UTC indication in combination with any of the above. This UTC indication may be coarse, e.g., accurate enough to make the H-SFN, SFN, subframe or slot number indication unambiguous. This may also be expressed in terms of an indication of the duration of the gap between the disappearance of the old cell and the appearance of the new cell (wherein the duration may zero, negative (e.g., < 0) or positive (e.g., > 0), e.g., in the form of the above-described CellSwitchGap-rXX IE (wherein the appearance of the new cell will be at the time equal to t- Service-r17 + CellSwitchGap-rXX. [0247] In some embodiments, the information related to the information related to the satellite orbit and feeder link propagation delay after the cell switch may include: the ephemeris parameters of the satellite serving the cell after the cell switch (including enough information to determine the satellite’s position and velocity at any point in time within a certain time period); the Common TA parameters to be applied after the cell switch; the K_mac value associated with the cell after the cell switch; and/or the NTN-Config-r17 IE associated with the cell and its serving satellite after the cell switch, or parts of the content of the NTN-Config-r17 IE, e.g., just the ephemerisInfo-r17 IE, the ta-Info-r17 IE, and possibly the kmac-r17. IE. As one option, inclusion of parts, but not all of the content of the NTN-Config-r17 IE in the assistance information may imply that the remaining (not included) parameters of the NTN- Config-r17 IE are reused from (e.g., have the same value as the corresponding parameters in) the NTN-Config-r17 IE before the cell switch. [0248] In some embodiments, the information related to the difference in timing may include one or more of: e.g., DL timing in terms of frame, subframe, slot, and/or symbol borders. [0249] In some embodiments, the information related to the timing of the SSB transmissions after the cell switch may include: an SMTC for the SS bursts after the cell switch. The reference can be the cell timing before the cell switch or the cell timing after the cell switch (where the latter requires that the UE is informed of the timing difference – e.g., difference in SFN and frame border timing – between the cell after the cell switch and the cell before the cell switch); and/or an indication of when SS bursts are transmitted after the cell switch, e.g., with microsecond accuracy for the start of the SS burst, optionally complemented by an SS burst duration and an SS burst periodicity indication. [0250] The above-described assistance information may facilitate for the UE to handle the cell switch in an efficient way. However, much of the assistance information may be omitted, potentially leading to less efficient UE operation in conjunction with the cell switch, but without rendering the system dysfunctional. For instance, the ephemeris and Common TA parameters to be applied after the cell switch may not be provided prior to the cell switch. Instead, the UE would have to obtain them from SIB19 after the cell switch. This will cause an interruption in the UE’s communication in conjunction with the cell switch until the UE has obtained SIB19 after the cell switch. However, an additional problem is that the UE may not acquire SIB19 as long as the validity time (e.g., the ntn-UlSyncValidityDuration-r17 IE) associated with the ephemeris and Common TA parameters from the UE’s latest SIB19 acquisition has not expired (or has sufficient margin until it will expire). This may extend the interruption by delaying the UE’s acquisition of SIB19 after the cell switch. [0251] This problematic UE behavior may be mitigated or solved by smart configuration, where the value of the ntn-UlSyncValidityDuration-r17 IE in NTN-Config-r17 in SIB19 (associated with the ephemeris and Common TA parameters in the serving cell) is set such that it will expire at the time of the cell switch, or before the cell switch but after the last SIB19 transmission before the cell switch, or between the last SIB19 transmission in the old cell (before the cell switch) and the first SIB19 transmission in the new cell (after the cell switch). Such a configuration would require that the ntn-UlSyncValidityDuration-r17 IE is updated at every SIB19 transmission. Since the granularity of the ntn-UlSyncValidityDuration-r17 IE is 5 seconds, the desired configuration properties cannot be achieved only by updating the ntn- UlSyncValidityDuration-r17 IE, so the gNB would also, or instead, have to finetune the epoch time associated with the ephemeris and Common TA parameter (e.g., the epochTime-r17 IE) to achieve that the validity time, e.g., the ntn-UlSyncValidityDuration-r17 IE, expires at the time of the cell switch, or between the last SIB19 transmission before the cell switch and the cell switch, or between the last SIB19 transmission in the old cell (before the cell switch) and the first SIB19 transmission in the new cell (after the cell switch). This configuration strategy would work also for legacy UEs, which may not implement reception and usage of the cell switch assistance information. [0252] With reference still to Figure 12, in block 1208 of method 1200, the UE may calculate and report its TA to be used after the cell switch even before the cell switch, and as a further option, if the network receives such a report before the cell switch, the network may send a Differential K_offset MAC CE (indicating the UE specific K_offset to use after the cell switch) to the UE either before or after the cell switch. If sent before the cell switch, a further option is that a new LCH ID or one of the reserved bits in the Differential K_offset MAC CE may be used to indicate that the updated UE specific K_offset is to be used after the cell switch (but the UE may also understand this without any explicit indication, based on the fact that it had reported a TA (as input to the network’s calculation of the UE specific K_offset) which is adapted to the post-switch conditions). [0253] In some embodiments, the UE may obtain DL synchronization after the cell switch by receiving the PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal) (e.g., an SSB transmission). This means that after the cell switch, the UE may be configured to wait for the first SSB transmission before it can obtain DL synchronization in the new cell. This may create an undesirable interruption in the communication. To mitigate this potential interruption, the network may be configured to execute the cell switch right before an SSB transmission. For instance, the SSB may be transmitted in the first slot after the cell switch. In some embodiments, an epoch time associated with the ephemeris parameters and the common TA parameters may be configured to cause validity time associated with the ephemeris parameters and the common TA parameters expires at time of cell switch. [0254] However, reception of the PSS and SSS after the cell switch may optionally not be needed to acquire DL synchronization in the new cell, and if the UE can do without it, the issue with the potential interruption time caused by the UE having to wait after the cell switch until the first SSB transmission is eliminated. [0255] For instance, if the network provides accurate enough information about the difference in DL timing between the new and the old cell (e.g., after and before the cell switch) as part of the assistance information, the UE may be able to recalculate its pre-switch DL to a post-switch DL synchronization with an error smaller than the cyclic prefix (e.g., the cyclic prefix (CP) used on the PUCCH -Physical Uplink Control Channel and/or the PUSCH – Physical Uplink Shared Channel) (and note that when the UE does this, it has to account for the difference in propagation delay from the reference point used for the DL timing difference indication to the UE before and after the cell switch). With sub-CP accuracy achieved through calculation, the UE can then use the DMRS (Demodulation Reference Signal) in DL transmissions, e.g., the DMRS in an UL grant (e.g., a PDCCH DMRS – or Physical Downlink Control Channel DMRS) to fine-tune its DL synchronization. The DL synchronization is used as the reference for the application of the UE’s (autonomously calculated) TA in UL transmissions. However, if the first transmission occasion that occurs in the new cell (in the DL to the UE or in the UL from the UE) is an uplink transmission using a preconfigured UL grant (e.g., a periodic configured UL grant configured by the ConfiguredGrantConfig IE), the UE will not receive any PDCCH DMRS to use to finetune its DL synchronization. In this case, the UE either will have to rely fully on its calculated DL synchronization or wait until it receives a DL transmission which it can use to finetune its DL synchronization, e.g., a PSS and/or an SSS. [0256] In some embodiments, there may be different conceivable ways to convey the assistance information described above to the UEs (e.g., the UE 112 of Figure 1, the device 508 of Figure 5, and/or the UE 1002 of Figure 10) in the cell. For example, with reference to Figure 12, in block 1202, the UE may receive the cell-switching assistance information from the network node in different ways. In some embodiments, broadcasting (e.g., by the network node) the assistance information may be the most preferable alternative from a resource efficiency point of view. However, whether broadcasting or dedicated signaling is the most resource efficient way to convey the assistance information depends on the conditions in the cell. If few UEs and many broadcast occasions can be assumed, then using dedicated signaling may be more resource efficient, but this would only work for UEs in RRC_CONNECTED state, while UEs in RRC_INACTIVE and RRC_IDLE state would be left on their own to handle the cell switch. [0257] Hence, using broadcasting is likely to be the preferred alternative, possibly complemented by optional dedicated signaling for UEs in RRC_CONNECTED state, e.g., to provide some UE specific assistance information, e.g., depending on the UE’s capabilities or the UE’s channel conditions or the UEs location in the cell. [0258] To broadcast the assistance information to the UEs in the cell, a straightforward signaling means is the system information. The assistance information can be included in the existing SIB19, which contains other information related to NTN. One or more new IE(s) can be introduced for this purpose. Possibly the NTN-NeighCellConfig-r17 IE, or the content of the NTN-NeighCellConfig-r17 IE can be reused for this purpose. To distinguish it from a regular neighbor cell, this can be an IE with a different name, or can have an explicit indication saying that the information concerns a cell that will take over the coverage area after a coming cell switch. Another way to indicate this can be the PCI, which, when the same as in the current serving cell, the UE would interpret as an indication that the information concerns a cell that will take over the coverage area after a coming cell switch. Otherwise, the PCI can optionally be excluded. Other assistance information described in the present disclosure may be included, e.g., an indication of when the cell switch will occur, an indication when the new cell will appear (after the cell switch), and/or an indication of the cell switch gap, e.g., in the form of the CellSwitchGap-rXX IE described in the above section. [0259] Another option is to introduce a new SIB for the assistance information. In either case, transmission/resources may be saved by sending the new SIB, or including the assistance information in SIB19, only in a subset of the scheduled broadcast occasions. Since the UEs will not use the assistance information until the cell switch occurs, or slightly before the cell switch to initiate the preparations, signaling overhead may be saved by not broadcasting the assistance information all the time, but only a rather short time before the cell switch occurs. One possible such strategy can be to broadcast the assistance information in a first broadcast occasion (for SIB19 or the new SIB) and then in all subsequent broadcast occasions (for SIB19 or the new SIB) until the cell switch occurs, and make sure that the first broadcast occasion occurs at a time so long before the cell switch that all UEs in the cell will receive the assistance information (disregarding UEs that attempt but fail to receive the broadcasted assistance information). [0260] If the assistance information is introduced as an extension in SIB19, and this extension is included in only a subset of the SIB19 transmissions, preferably the transmission occasions(s) close in time to the cell switch, no specific means is needed to make the UEs obtain it, as long as the assistance information is included in a SIB19 broadcast occasion (and all subsequent SIB19 broadcast occasions until the cell switch occurs) that occurs a longer time in advance (e.g., before the cell switch) than the validity time associated with the ephemeris and Common TA parameters for the serving cell (e.g., the ntn-UlSyncValidityDuration-r17 IE in the NTN-Config-r17 IE for the serving cell) plus a time period to account for the time that will elapse from the last SIB19 transmission before the cell switch until the cell switch. When determining this first SIB19 broadcast occasion to include the assistance information in, the value of the ntn-UlSyncValidityDuration-r17 IE to be used may e.g., be the largest value of the ntn-UlSyncValidityDuration-r17 IE for the serving cell used in the cell. The value of the second time period, e.g., the time period taking the time between the last SIB19 transmission before the cell switch and the cell switch into account, can e.g., be the exact length of the time period between the last SIB19 transmission before the cell switch and the cell switch, optionally with some added margin, or, for simplicity, it may be the length of the broadcast period for SIB19 in the serving cell (possibly with some margin, e.g., a margin equal to (or slightly larger) than the SI window used in the cell). [0261] The purpose of using this way to determine when to start including the assistance information in the periodic SIB19 transmissions is to ensure that all UEs will receive a SIB19 transmission in which the assistance information is included, e.g., it should be precluded that a UE receives a SIB19 transmission without the assistance information, but with a value of the ntn-UlSyncValidityDuration-r17 IE that is so large that the validity time will not expire before the cell switch or will expire after the last SIB19 transmission before the cell switch. [0262] If the assistance information is included in a new SIB, this new SIB will not have the dependence of the validity time configured by the ntn-UlSyncValidityDuration-r17 IE as SIB19 does. Hence, the first transmission of the new SIB can be later than the time of the first SIB19 transmission including assistance information described above. One option is to only transmit the new SIB once, e.g., using the last broadcast occasion before the cell switch. However, it is preferable that UEs are aware that one or more transmission(s) of the new SIB will occur. The presence of scheduling information for the new SIB in SIB1 may be used as an indication of this, and a further option can be to extend this scheduling information with an indication of when the transmission(s) of the new SIB will occur. Alternatively, only the legacy si-BroadcastStatus IE (which may have either of the values “broadcasting” or “notBroadcasting”) in the SchedulingInfo IE in SIB1 to indicate when the new SIB is broadcasted. A disadvantage of this would be that the UE will not know in advance, but would have to check the si-BroadcastStatus IE, possibly multiple times, prior to attempting to receive the new SIB. An additional option can be to slightly modify the interpretation of the value “notBroadcasting” for the si-BroadcastStatus IE. Normally, this values not only means that the associated SI message (and the SIB(s) it contains) are not periodically broadcasted, but also implies that this SI message is available on request. An optional modification of this interpretation of the value “notBroadcasting” for the si-BroadcastStatus IE for the new SIB can be that “notBroadcasting” only means that the associated SI message is not periodically broadcasted, but does not imply that the SI message is available on request. [0263] Another possibility to indicate when the new SIB is broadcast can be to have an indication in SIB19, which, when set or present, can mean that the periodic broadcasting of the new SIB has started (and will continue until the cell switch occurs). Alternatively, the indication, when set or present, can mean that the new SIB is currently being periodically broadcasted (which in practice would mean that the indication says that the new SIB at the new SIB’s next broadcast occasion in accordance with the scheduling information in SIB1. [0264] With reference to Figure 13, the cell-switching assistance information described with respect to method 1300 may facilitate for the UE to handle the cell switch in an efficient way, and the network node may provide all or a subset of it to the UEs in the cell prior to the cell switch. However, in some instances, some or much of the assistance information may be omitted (e.g., not specified), potentially leading to less efficient UE operation in conjunction with the cell switch, but without rendering the system dysfunctional. For instance, the ephemeris and Common TA parameters to be applied after the cell switch may not be provided prior to the cell switch. Instead, the UE may obtain them from SIB19 after the cell switch. Such timing may cause an interruption in the UE’s communication in conjunction with the cell switch until the UE has obtained SIB19 after the cell switch. However, an additional problem is that the UE may not acquire SIB19 as long as the validity time associated with the ephemeris and Common TA parameters in the serving cell (e.g., the ntn-UlSyncValidityDuration-r17 IE) from the UE’s latest SIB19 acquisition (which occurred before the cell switch) has not expired (or as long as it has sufficient margin until it will expire). This may extend the interruption by delaying the UE’s acquisition of SIB19 after the cell switch. [0265] Such problematic UE behavior may be mitigated or solved by smart configuration, where the value of the ntn-UlSyncValidityDuration-r17 IE in the NTN-Config-r17 IE in SIB19 (associated with the ephemeris and Common TA parameters in the serving cell before the cell switch) is set so that it will expire at the time of the cell switch, or before the cell switch but after the last SIB19 transmission before the cell switch, or between the last SIB19 transmission in the old cell (before the cell switch) and the first SIB19 transmission in the new cell (after the cell switch). Such a configuration would require that the ntn-UlSyncValidityDuration-r17 IE is updated at every SIB19 transmission. Since the granularity of the ntn- UlSyncValidityDuration-r17 IE is 5 seconds, the desired configuration properties may not be achieved only by updating the ntn-UlSyncValidityDuration-r17 IE. In such instances, the network node may be configured to finetune the epoch time associated with the ephemeris and Common TA parameter (e.g., the epochTime-r17 IE) such that the validity time (e.g., the ntn- UlSyncValidityDuration-r17 IE; also referred to as timer T430) expires at the time of the cell switch, or between the last SIB19 transmission before the cell switch and the cell switch, or between the last SIB19 transmission in the old cell (before the cell switch) and the first SIB19 transmission in the new cell (after the cell switch). This configuration strategy would work also for legacy UEs, which may not implement reception and usage of the cell switch assistance information. [0266] With reference to Figure 13, in block 1304, In some embodiments, the network may receive a report from the UE (e.g., in the form of a Timing Advance Report MAC CE) about the UE’s TA to be used in the new cell. In block 1308 of method 1300, to optimize the UE’s operation after the cell switch, the network may provide the UE with a UE specific K_offset value. In some embodiments, the K_offset value may be signaled using the Differential K_offset MAC CE. Additionally or alternatively, the UE may calculate and report its TA to be used after the cell switch even before the cell switch. [0267] With reference still to Figure 13, in instances in which the network receives such a report before the cell switch, the network may send a Differential K_offset MAC CE (indicating the UE specific K_offset to use after the cell switch) to the UE either before or after the cell switch. In instances in which the UE specific K_offset value is sent before the cell switch, a further option is that a new LCH ID (Logical Channel ID) or one of the reserved bits in the Differential K_offset MAC CE may be used to indicate that the updated UE specific K_offset is to be used after the cell switch (but the UE may also understand this without any explicit indication, based on the fact that it had reported a TA (as input to the network’s calculation of the UE specific K_offset) which is adapted to the post-switch conditions). [0268] In some embodiments, the cell switch may be performed as a soft switch. For instance, a first cell associated with a source network node (e.g., the source network node 1104 of Figure 11) and a second cell associated with a target network node (e.g., the target network node 1106 of Figure 11) may at have an overlap period. During a soft switch, using the same carrier frequency for both the old and the new cell potentially creates problematic interference during the coexistence/overlap period. Furthermore, using the same PCI for the old and the new cell may increase the consequences of the interference and make it more difficult to distinguish transmissions in the old cell from transmissions in the new cell, e.g., because the PCI based scrambling will be the same in both cells. [0269] The problems may be alleviated by configuring the old and the new cell such that the SSB transmissions in the first and the second cell are time shifted in relation to each other, thereby preventing that they interfere with each other. [0270] An RRC_CONNECTED UE is well aware of the timing of its serving cell’s SSB transmissions, so RRC_CONNECTED UEs can easily distinguish the time shifted SSB transmissions in the new cell from the SSB transmissions in the old cell. The same should be valid for UEs in RRC_INACTIVE and RRC_IDLE state. [0271] With the same relation between SSB transmissions and SIB1 transmissions before and after the cell switch, the same time shifting would apply to the SIB1 transmissions, thereby avoiding interference between them. The remaining system information (SI) (e.g., the SI messages; SystemInformation RRC messages) carrying all other SIBs, are more problematic to handle with time shifting, because it may be difficult to fit all SI windows of both cells on the same timeline without overlaps. Hence, although time shifting of the SI windows for the first cell and the second cell may be feasible, and can be a potential solution when the number of SI windows is small and/or their periodicities are long, an improved way to avoid interference between the SI message transmissions in the first cell and the second cell may be to separate the SI message transmissions in the old and the new cell in the frequency domain. In these and other embodiments, different and/or disjoint (without overlap) CORESETs can be configured for the first cell and the second cell. This would mean that the ControlResourceSet IE identified by the controlResourceSetId field in the SearchSpace IE identified by the searchSpaceOtherSystemInformation field would configure disjoint frequency resources (configured by the frequencyDomainResources field in the ControlResourceSet IE) for the old and new cell. [0272] In some embodiments, another way to cope with the potentially overlapping SI windows of the first cell and the second cell may be to cause the network node serving the first cell to cancel the SI message transmissions in the first cell during the period of coexistence/overlap with the second cell. In these and other embodiments, the SI windows may concern transmissions of both SIB IEs and SIBpos IEs (where the latter contain assistance data for positioning). [0273] In some embodiments, the interference problems between the first cell and the second cell may be mitigated by configuring PRACH resources such that PRACH resources in the first cell and the second cell do not coincide or overlap in both the time domain and the frequency domain (e.g., separation in either the time domain or the frequency domain or both is preferable). [0274] Additionally or alternatively, coordination of the scheduling of transmissions to and from the UEs should preferably be used so that they do not interfere with each other during the period of coexistence/overlap between the old and the new cell. [0275] In instances in which the separation in the time domain (e.g., time shifting) is used to avoid interference, margins in the form of guard times will be needed to account for the difference in propagation delay between the two cells as well as in different parts of the cells. [0276] Information about time shifting and/or disjoint CORESETs can optionally be part of the assistance information sent to the UEs in the old cell prior to the cell switch. [0277] In Figure 13, a method is described in which the network node serving the cell before the cell switch repeatedly adjusts the validity time (e.g., the ntn- UlSyncValidityDuration-r17 IE) and/or the epoch time (e.g., the epochTime-r17 IE) of the ephemeris and Common TA parameters for the serving cell in SIB19 to achieve that the validity time, e.g., the ntn-UlSyncValidityDuration-r17 IE, expires at the time of the cell switch or between the last SIB19 transmission before the cell switch and the cell switch. Such network node implementation-based method can be used for soft switch too, with the epoch time and validity time in the old cell set so that the validity time (e.g., the ntn-UlSyncValidityDuration- r17 IE) expires at the end of the coexistence/overlap period, or between the last SIB19 transmission in the old cell and the end of the coexistence/overlap period, or sometime during the coexistence/overlap, or before the first SIB19 transmission in the new cell but after the last preceding SIB19 transmission in the old cell. [0278] Another possibility to mitigate the interference problem during the coexistence/overlap period can be to divide the subcarriers into two pools, one for the old cell and one for the new cell (e.g., separation in the frequency domain). This can, as one option, be applied only to scheduled channels, e.g., the DLSCH (Downlink Shared Channel) and the PUSCH, but potentially also to the PDCCH, the PUCCH and/or the PRACH or Physical Random Access Channel (which would require reconfiguration of the UE in conjunction with the cell switch). SSB transmissions may not be subject to the frequency separation, as interference between the SSB transmissions in the old and the new cell may be avoided using time shifting (as described above). [0279] Currently, the NTN-Config of a neighbor cell (indicated by PCI) served by a neighbor satellite is informed in SIB19, and in the reconfigurationWithSync IE in the RRCReconfiguration message in case of (C)HO. For hard cell switch with unchanged PCI and carrier frequency, in case of a satellite switch, the old and the new satellite serve the cell in non-overlapping time periods (where, as previously explained, for simplicity, the pre-switch conditions may be referred to as the old cell and the post-switch conditions may be referred to as the new cell), and since the same PCI (and carrier frequency) is used before and after the cell switch, the PCI cannot be used to differentiate whether NTN-Config is for the old satellite/cell or the new satellite/cell. To resolve this, additional information can be associated with NTN-Config, where such information e.g., can be a satellite identifier or a simple indicator (e.g., one bit) indicating that the NTN-Config is for a satellite that will serve the cell in the future (e.g., after the cell switch). [0280] Furthermore, for hard cell switch with unchanged PCI and carrier frequency, it is not necessary to send any switch complete command/indication via the new satellite after the cell switch since the cell (from the UE’s perspective) is not changed (assuming that the cell is at least locally defined by the PCI and carrier frequency). The network node can just schedule UL and DL transmissions after the UE is switched to the new satellite. To implement this, the network node shall not trigger the UE to switch by sending an RRCReconfiguration message containing a reconfigurationWithSync IE, and the NTN-Config of the new satellite and the associated satellite identifier, or the simple indicator, can be provided to the UE in an RRCReconfiguration message without a reconfigurationWithSync IE, or in a SIB (e.g., extending SIB19 or using a new SIB). Alternatively, the associated satellite identifier or simple indicator may not be informed explicitly, when the UE receives NTN-Config in an RRCReconfiguration message without a reconfigurationWithSync IE, or in a new SIB, or in SIB19 while the associated cell identifier is empty or absent or set to a specific value, because the UE may interpret this as an implicit indication to consider the NTN-Config to be for a satellite appearing in the future. [0281] In the present disclosure, the term Non-Terrestrial Network (NTN) may, depending on the context, refer to either or both of NR NTN and IoT NTN, but mostly the term is used to refer to only NR NTN. [0282] In the present disclosure, the embodiments outlined are described mainly in terms of NR based NTNs, but they are also equally applicable in an NTN based on LTE technology (and in particular IoT NTN). [0283] In the present disclosure, there are two main deployment principles for NTN: quasi- Earth-fixed cells and Earth-moving cells. These deployment principles are also referred to by other names. The quasi-Earth-fixed cells deployment principle is also referred to as quasi- Earth-fixed beams. The Earth-moving cells deployment principle is also referred to as Earth- moving beams, or shorter, moving cells or moving beams (where moving cells is the preferred term in this solution description). [0284] In the present disclosure, the term “network” is used in the solution description to refer to a network node, which typically will be a gNB (e.g., in a NR based NTN), but which may also be an evolved Node B or eNB (e.g., in a LTE based NTN), or a base station or an access point in another type of network, or any other network node with the ability to directly or indirectly communicate with a UE. Refinements with finer granularity are also conceivable. For instance, a gNB may be an en-gNB (e.g., a gNB that can connect with EPC and eNB), and if a split gNB architecture is applied (dividing the gNB into multiple separate entities or notes), the term “node” may refer to a part of the gNB, such as a gNB Central Unit or a gNB-CU (often referred to as just CU), a gNB Distributed Unit or a gNB-DU (often referred to as just DU), a gNB-CU-CP (gNB-CU Control Plane) or a gNB-CU-UP (gNB-CU User Plane). Similarly, an eNB may be a next generation eNB or an ng-eNB, and if a split eNB architecture is applied (dividing the eNB into multiple separate entities or notes), the term “network” (and the network node it implies) may refer to a part of the eNB, such as an eNB-CU, an eNB-DU, an eNB-CU- CP or an eNB-CU-UP. Furthermore, the term “network” (and the network node it implies) may also refer to an IAB-donor, IAB-donor-CU, IAB-donor-DU, IAB-donor-CU-CP, or an IAB- donor-CU-UP, where IAB stands for Integrated Access and Backhaul. [0285] In the present disclosure, ephemeris data is associated with (and applies to) a satellite. However, for convenience, ephemeris data may sometimes be described as associated with a cell, when the ephemeris data referred to actually is associated with the satellite serving the cell. This convenience practice may be seen e.g., in expressions like “a cell’s ephemeris data” or “the ephemeris data of the cell”. Such expressions should be interpreted as short forms of more strictly correct expressions like “a cell’s serving satellite’s ephemeris data”, “the ephemeris data of the cell’s serving satellite” or “the ephemeris data of the satellite serving the cell”. [0286] In the present disclosure, the terms “source node”, “target node” and “candidate target node” may be used in this document. The “node” in these terms should be understood as typically being a RAN node in an NTN based on NR technology, LTE technology or any other RAT (Radio Access Technology) in which handover, conditional handover or another conditional mobility concept is defined. In an NR based NTN, such a RAN node may be assumed to be a gNB. In an LTE based NTN (including an IoT NTN), such a RAN node may be assumed to be an eNB. Alternatives to, or refinements of, these interpretations are however also conceivable. For instance, a gNB may be an en-gNB, and if a split gNB architecture is applied (dividing the gNB into multiple separate entities or notes), the term “node” may refer to a part of the gNB, such as a gNB-CU (often referred to as just CU), a gNB-DU (often referred to as just DU), a gNB-CU-CP or a gNB-CU-UP. Similarly, an eNB may be an ng-eNB, and if a split eNB architecture is applied (dividing the gNB into multiple separate entities or notes), the term “node” may refer to a part of the eNB, such as an eNB-CU, an eNB-DU, an eNB-CU- CP or an eNB-CU-UP. Furthermore, the “node” in the terms may also refer to an IAB-donor, IAB-donor-CU, IAB-donor-DU, IAB-donor-CU-CP, or an IAB-donor-CU-UP. [0287] In the present disclosure, the terms “Handover Command” and “HandoverCommand” are used interchangeably herein. Both terms refer to a UE configuration the target node (of a regular handover) or candidate target node (of a conditional handover), during the (conditional) handover preparation phase, compiles for the UE to be subject to the handover or conditional handover. This UE configuration is compiled in the form of an RRCReconfiguration message which is conveyed to the UE via the source node. The RRCReconfiguration is associated with a certain target cell or candidate target cell and the UE applies the RRCReconfiguration when/if it accesses the concerned (candidate) target cell controlled by the (candidate) target node. Formally, “HandoverCommand” is an RRC inter- node message which is conveyed from a target node or a candidate target node to a source node during the preparation of a handover or a conditional handover. It is carried by the HANDOVER REQUEST ACKNOWLEDGE XnAP in the Target NG-RAN node To Source NG-RAN node Transparent Container IE. The “HandoverCommand” RRC inter-node message contains an RRCReconfiguration the UE should apply when accessing the target cell or candidate target cell. The source node forwards this RRCReconfiguration (e.g., the HandoverCommand) to the UE. In this solution description, the term “HandoverCommand” is also used to denote this RRCReconfiguration when it is stored in a UE as a part of a CHO configuration. This is also called the condRRCReconfig-r16 IE in the CondReconfigToAddMod-r16 IE (which contains the CHO configuration) in the CondReconfigToAddModList-r16 IE in the ConditionalReconfiguration-r16 IE. In the context of CHO, the terms “Conditional Handover Command”, “(Conditional) Handover Command” and “(conditional) Handover Command” may also be used. [0288] In the present disclosure, when CHO is configured for a UE, a cell which the UE potentially can connect to (e.g., if the CHO execution condition is fulfilled for the cell) is denoted as “candidate target cell”. Similarly, a RAN node controlling a candidate target cell is denoted as “candidate target node” or, in NR and NR NTN, “candidate target gNB”. However, once the UE has detected a fulfilled CHO execution condition for a candidate target cell, this terminology becomes a bit blurred. At this point, during the actual execution of the CHO and when the UE has connected to the new cell, the concerned cell may be referred to as either a “candidate target cell” or a “target cell”. Similarly, a RAN node controlling such a cell, may in this situation be referred to as either a “candidate target node” (or “candidate target gNB”) or a “target node” (or a “target gNB”). [0289] In the present disclosure, a condition included in a CHO configuration governing the execution of the conditionally configured procedure may be referred to as a CHO execution condition, a HO execution condition, a CHO trigger condition, a HO trigger condition or sometimes just a trigger condition. Furthermore, phases of the procedure may be referred to as the Handover Preparation phase, the Handover Execution and/or the Handover Completion phase, or may be referred to as the Conditional Handover Preparation phase (or the (conditional) Handover Preparation phase), the Conditional Handover Execution phase and/or the Conditional Handover Completion phase. [0290] In the present disclosure, when writing message names of a communication protocol, two equivalent principles are used in this document. The writing principle “<protocol name> <message name> message”, for example “XnAP HANDOVER REQUEST message”, and the writing principle “<message name> <protocol name> message”, for example “HANDOVER REQUEST XnAP message” are equivalent, both referring to a message (e.g., “<message name>”) of a communication protocol (e.g., “<protocol name>”), e.g., the HANDOVER REQEUST message of the communication protocol XnAP. The same writing format equivalence applies to other communication protocols, such as NGAP. [0291] In the present disclosure, the terms information element (IE) and field are used more or less interchangeably in this document. Also, the term parameter is sometimes used to denote the same concept. [0292] In the present disclosure, parameters/IEs/fields used in ASN.1 code as well as in procedural text in the 3GPP RRC specification for 5G/NR, e.g., 3GPP TS 38.331 version 17.5.0, are often named with a suffix indicating the number of the release of the 3GPP standard the parameter/IE/field was introduced in (e.g., the suffix “-r17” for a parameter/IE/field introduced in release 17 of the 3GPP standard). Parameters/IEs/fields following this naming convention are typically referred to both with and without the suffix, where the name including the suffix is used in the ASN.1 code (and thus defines the formal name from the ASN.1 compiler’s perspective), while the name without the suffix is used in running text, e.g., in field descriptions and procedural text. Relevant examples in the context of this document include the parameters/IEs/fields t-Service-r17 / t-Service and NTN-Config-r17 / NTN-Config. In this document, both name variants may occur for various parameters/IEs/fields. [0293] In the present disclosure, during the Handover Preparation phase of an inter-node handover, the source node sends an inter-node RRC message to the target node (or to the candidate target node in case of conditional handover), denoted as the HandoverPreparationInformation message. This inter-node RRC message contains the UE’s configuration in the source cell, in particular the RRC related configuration. To convey the HandoverPreparationInformation message to a target node (or to a candidate target node), the source node includes it in the HANDOVER REQUEST XnAP message (in case of an Xn based HO or CHO) or in a HANDOVER REQUIRED NGAP message (in case of an NG based HO or CHO), and in case of an NG based HO or CHO, the core network (represented by an AMF) will forward it to the candidate target node in the HANDOVER REQUEST NGAP message. [0294] In the present disclosure, when accessing a target cell during a HO or a CHO, the first message the UE sends to the target node in the target cell, after having sent a random access preamble and having received a Random Access Response message, is an RRCReconfigurationComplete message, indicating the successful completion of the HO or CHO. It should be noted that this RRCReconfigurationComplete message is often referred to as a Handover Complete message. [0295] In the present disclosure, the target cell configuration (RRCReconfiguration for the UE to use in the candidate target cell, e.g., the Handover Command, which is constructed by the candidate target node) and the CHO execution condition for each candidate target cell provided by the network to the UE is also known as the CHO configuration. The RRCReconfiguration message sent from the source/serving node conveying such a CHO configuration to the UE during the (conditional) Handover Preparation phase may contain a list of CHO configurations. Further CHO configurations may also subsequently be added to the list, and/or configured CHO configurations may be removed from the list, wherein RRCReconfiguration messages are used in both cases. Furthermore, the information provided from the source node to a candidate target node during the CHO preparation phase, e.g., in the HANDOVER REQUEST XnAP message or in the HANDOVER REQUIRED and HANOVER REQUEST NGAP message, e.g., the UE’s source cell configuration (e.g., the UE context) and the indication that the prepared handover is conditional, is also referred to as a CHO configuration, albeit in the context of configuration information in a candidate target node. Moreover, all the target cell configurations and their associated CHO execution conditions that the UE has been configured with, and which (according to 3GPP TS 38.331 version 17.5.0) may be stored in the UE variable "VarConditionalReconfig”, may sometimes collectively be referred to as the CHO configuration. Hence, it may be noted that this terminology is not always consistent. [0296] In the present disclosure, in a time-based CHO configuration for a certain candidate target cell, a time window is defined within which the configured UE may execute the CHO, provided that the signal strength/quality CHO execution condition is fulfilled, and outside which the UE may not execute the CHO. In this document, this time window may be referred to using a variety of terms, e.g., “CHO execution time window”, “CHO time window”, “CHO execution window”, “CHO window”, “time-based CHO time window” or simply “time window”. A CHO execution time window is said to last between the times T1 and T2, where T1 is represented by the t1-Threshold-r17 field and T2 is derived from the t1-Threshold-r17 field combined with the duration-r17 field, such that T2 = t1-Threshold-r17 + duration-r17. Both the t1-Threshold-r17 field and duration-r17 field are included in the condEventT1-r17 IE, which in turn is included in the CondTriggerConfig-r16 IE, which in turn is included in the ReportConfigNR IE. The t1-Threshold-r17 field is a UTC timestamp and the duration-r17 field represents a time period between 100 ms and 600 seconds (in steps of 100 ms). [0297] In the present disclosure, when the term “(conditional) target cell” is used (e.g., with parentheses around “conditional”), this should be interpreted as “target cell or conditional target cell” (e.g., the statement applies both when the concerned cell is a target cell and when it is a conditional target cell). When the term “(conditional) handover” is used (e.g., with parentheses around “conditional”), this should be interpreted as handover or conditional handover (e.g., the statement applies to both handover and conditional handover). When the term “(conditional) target cell” is used (e.g., with parentheses around “conditional”), this should be interpreted as “target cell or conditional target cell” (e.g., the statement applies both when the concerned cell is a target cell and when it is a conditional target cell). When the term “(conditional) target gNB” is used (e.g., with parentheses around “conditional”), this should be interpreted as “target gNB or conditional target gNB” (e.g., the statement applies both when the concerned gNB is a target gNB and when it is a conditional target gNB). When the term “(conditional) target node” is used (e.g., with parentheses around “conditional”), this should be interpreted as “target gNB or conditional target node” (e.g., the statement applies both when the concerned node is a target node and when it is a conditional target node). [0298] In the present disclosure, the fact that the carrier frequency and PCI remain unchanged after the cell switch (see, e.g., paragraphs [0197]-[0199] herein) makes it look (from the UE’s point of view) as the same cell, e.g., the UE will perceive it as the same cell before and after the cell switch (assuming that the carrier frequency and the PCI – at least locally – defines the cell). Because of this circumstance, it is questionable if this kind of switch should be referred to as a cell switch. Still, for convenience and simplification of the description, the cell switch will often be referred to as a cell switch, and the pre-switch conditions may be referred to as the old cell (or sometimes the source cell) and the post-switch conditions may be referred to as the new cell (or sometimes the target cell). [0299] Herein it is described that a UE can be provided with information that facilitates for it to handle an upcoming (cell) switch (due to a feeder link switch and/or satellite switch) with unchanged PCI and carrier frequency. This information is herein referred to as “assistance information”, “configuration information”, “switch assistance information” or just “information”. [0300] In the present disclosure, the solution is generally described for the hard switch scenario. Some aspects related to the solution’s applicability in the soft switch scenario are described in paragraphs [0268] to [0278] herein (and to an extent also in other paragraphs). [0301] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware. [0302] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

Claims

CLAIMS 1. A method performed by a user equipment (UE) for performing a cell switch, the method comprising: receiving (1202), from a network node, cell-switching assistance information for performing the cell switch with unchanged physical cell identity (PCI); and performing (1210) the cell switch from a first cell to a second cell based on the cell- switching assistance information.

2. The method of claim 1, wherein the first cell and the second cell are associated with a first satellite and a second satellite, respectively.

3. The method of claim 2, wherein the first satellite and the second satellite are same.

4. The method of claim 2, wherein the first satellite is different from the second satellite.

5. The method of any of claims 2-4, wherein the cell-switching assistance information comprises one or more: information related to satellite orbit and feeder link propagation delay related to the second satellite during and/or after the cell switch; information related to timing of synchronization signal block (SSB) transmissions from the second satellite during and/or after the cell switch; and information related to transmission configuration indicator (TCI) states including satellite information associated with the second satellite.

6. The method of claim 5, wherein the timing of the SSB transmissions during and/or after the cell switch includes an indication of timing of synchronization signal bursts during and/or after the cell switch.

7. The method of any of claims 5-6, wherein the information related to the satellite orbit and the feeder link propagation delay related to the second satellite during and/or after the cell switch comprises one or more of: ephemeris parameters of the second satellite during and/or after the cell switch; or common timing advance (TA) parameters related to the second satellite.

8. The method of claim 7, further comprising: determining (1204) a timing advance for the UE to use after the cell switch, based on the ephemeris parameters and the common TA parameters.

9. The method of claim 8, further comprising: sending (1206), to the network node, the timing advance for the UE to use after the cell switch.

10. The method of claim 9, further comprising: receiving (1208), from the network node, a K_offset parameter value to use after the cell switch.

11. The method of any of claims 7-10, wherein the UE receives the ephemeris parameters and the common TA parameters from the network node using system information block type 19 (SIB19).

12. The method of claim 11, wherein an epoch time associated with the ephemeris parameters and the common TA parameters is configured to cause validity time associated with the ephemeris parameters and the common TA parameters expires at time of cell switch.

13. The method of any of claims 1-12, wherein the cell-switching assistance information comprises one or more: information related to timing of the cell switch; and information related to general properties of the cell switch, the information related to the general properties of the cell switch including one or more of: PCI of the second cell, or an indication of a type of the cell switch.

14. The method of claim 13, wherein the type of the cell switch is a first type or a second type, wherein the first type includes cell switches without a period of overlap between the first cell and the second cell, and the second type includes cell switches with at least a partial period of overlap between the first cell and the second cell.

15. The method of any of claims 13-14, wherein the timing of the cell switch includes appearance of the second cell.

16. The method of any of claim 13-15, wherein the timing of the cell switch is indicated by a gap length representing time between disappearance of the first cell and appearance of the second cell.

17. The method of any of claims 1-16, wherein the cell-switching assistance information comprises one or more: information related to a difference in timing between the first cell and the second cell; information related to location and coverage of the second cell; and information related to provision or transfer of the cell-switching assistance information or configuration information to the UE.

18. The method of any of claims 1-17, wherein performing the cell switch based on the cell- switching assistance information comprises: applying at least a portion of the cell-switching assistance information for the second cell; and restarting a validity timer.

19. The method of any of claims 1-18, wherein the UE receives the cell-switching assistance information from the network node via broadcasting.

20. The method of any of claims 1-19, wherein the UE receives the cell-switching assistance information from the network node via dedicated signaling.

21. The method of any of claims 1-20, wherein the cell-switching assistance information includes an indication that the cell-switching assistance information is related to the second cell.

22. The method of claim 21, wherein the indication is included in system information block type 19 (SIB19) as part of NTN-NeighCellConfig-r17 information block (IE).

23. A method performed by a network node for facilitating a user equipment (UE) to perform a cell switch from a first cell to a second cell, the method comprising: sending (1302) cell-switching assistance information to the UE, wherein the cell switch is based on the cell-switching assistance information with unchanged physical cell identity (PCI).

24. The method of claim 23, wherein the cell-switching assistance information comprises one or more: information related to satellite orbit and feeder link propagation delay during and/or after the cell switch; information related to timing of synchronization signal block (SSB) transmissions during and/or after the cell switch; and information related to transmission configuration indicator (TCI) states including satellite information associated with a satellite serving the second cell.

25. The method of any of claims 23-24, wherein the information related to the satellite orbit and the feeder link propagation delay during and/or after the cell switch comprises one or more of: ephemeris parameters of the satellite serving the second cell during and/or after the cell switch; or common timing advance (TA) parameters related to the satellite serving the second cell.

26. The method of any of claims 23-25, wherein the network node sends the ephemeris parameters and the common TA parameters from the network node using system information block type 19 (SIB19).

27. The method of any of claims 23-25, further comprising: adjusting validity time of the ephemeris parameters and the common TA parameters associated with the first cell to cause validity of the ephemeris parameters to expire at: a time of the cell switch; or a time between last transmission of the ephemeris parameters and the common TA parameters, and the cell switch.

28. The method of any of claims 23-27, wherein the adjusting validity time comprises: adjusting an epoch time associated with the ephemeris parameters and the common TA parameters.

29. The method of any of claims 23-28, further comprising: receiving (1304), from the UE, a timing advance for the UE to use after the cell switch.

30. The method of any of claims 29, further comprising: determining (1306) a UE-specific K_offset parameter value to use after the cell switch based on the timing advance; and sending (1308), to the UE, the UE-specific K_offset parameter value to use after the cell switch.

31. The method of any of claims 23-30, wherein the cell-switching assistance information comprises one or more: information related to timing of the cell switch; and information related to general properties of the cell switch, the information related to the general properties of the cell switch including one or more of: PCI of the second cell, or an indication of a type of the cell switch.

32. The method of claim 31, wherein the type of the cell switch is a first type or a second type, wherein the first type includes cell switches without a period of overlap between the first cell and the second cell, and the second type include cell switches with at least a partial period of overlap between the first cell and the second cell.

33. The method of any of claims claim 23-32, wherein the cell-switching assistance information comprises one or more: information related to a difference in timing between the first cell and the second cell; information related to location and coverage of the second cell; and information related to provision or transfer of the cell-switching assistance information or configuration information to the UE.

34. The method of any of claims 23-33, wherein sending the cell-switching assistance information comprises: broadcasting the cell-switching assistance information to the UE.

35. The method of any of claims 23-34, wherein sending the cell-switching assistance information comprises: sending the cell-switching assistance information to the UE using dedicated signaling.

36. The method of any of claims 23-35, wherein at least a part of the cell-switching assistance information is sent as part of system information block type 19 (SIB19) message.

37. A user equipment for performing a cell switch, comprising: processing circuitry configured to perform the steps of any one of claims 1-22; and power supply circuitry configured to supply power to the processing circuitry.

38. A network node for facilitating a user equipment to perform a cell switch, the network node comprising: processing circuitry configured to perform the steps of any one of claims 23-36; and power supply circuitry configured to supply power to the processing circuitry.

39. A user equipment (UE) for performing a cell switch, the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform the steps of any one of claims 1- 22; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.