Inter-node mobility management

Abstract

Apparatuses and techniques for supporting inter-node mobility management are disclosed herein. An example apparatus may be a first base station. The first base station may include a processor configured to determine that a connection establishment condition has been satisfied. The connection establishment condition may be associated with satellite positioning relative to a location. The first base station may initiate a random access channel (RACH) procedure with a second base station based on the connection establishment condition being satisfied. The first base station may establish a Uu link between the first base station and the second base station. The Uu link may be established through a satellite link. The first base station may receive mobility management signaling from the second base station via the Uu link.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 395,513, filed on August 5, 2022, the contents of which are hereby incorporated by reference into this document. Background Art

[0003] Non-terrestrial networks (NTNs) may facilitate the deployment of wireless networks in some areas.

[0004] The basic NTN may include an airborne or satellite-based platform that transmits signals between a land-based g-node B (gNB) and a user equipment (UE). Signals may be transmitted between the gNB and the UE via a gateway (GW). Release 17 (Rel-17) of the New Radio (NR) NTN standard may support power class 3 UEs with omnidirectional antennas and linear polarization. Rel-17 may also support very small aperture antenna (VSAT) terminals with directional antennas and circular polarization. Rel-17 NTN UEs may be able to communicate with a global navigation satellite system (GNSS).

[0005] Aerial or spaceborne platforms can be classified according to orbit. For example, a low earth orbit (LEO) satellite can orbit at an altitude between 300km and 1500km. As another example, a geostationary orbit (GEO) satellite can orbit at an altitude of 35786km. As another example, a medium earth orbit (MEO) satellite can orbit at an altitude between 7000km and 25000km. As another example, a high altitude platform station (HAPS) can be located at an altitude between 8km and 50km. Satellite platforms can be further classified as having a "transparent" or "regenerative" payload. Transparent satellite payloads implement frequency conversion and RF amplification in both uplink and downlink. In some cases, multiple transparent satellites can be connected to one land-based gNB. Regenerative satellite payloads can implement full gNB or gNB distributed units (DUs) on satellites. The regenerative payload can perform digital processing (e.g., demodulation, decoding, recoding, remodulation, and / or filtering) on ​​the signal. Summary of the invention

[0006] Devices and techniques for inter-node mobility management are provided herein.

[0007] An example device may be a first base station, the first base station comprising a processor configured to perform one or more actions. The first base station may determine that a connection establishment condition has been met. The connection establishment condition may be associated with a satellite positioning relative to a certain location. The first base station may initiate a random access channel (RACH) procedure with a second base station based on the connection establishment condition being met. The first base station may establish a Uu link between the first base station and the second base station. The Uu link may be established via a satellite link. The first base station may receive mobility management signaling from the second base station via the Uu link.

[0008] The connection establishment condition may be satisfied by a satellite position being within a distance threshold from the location. The connection establishment condition may be satisfied by a first time associated with a satellite position being within a fixed timing offset from a second time associated with the satellite position passing through the location. The RACH procedure may be initiated using resources dedicated to inter-base station communications.

[0009] The first base station may detect signaling associated with a cell dedicated to inter-base station communication or a cell on which inter-base station communication is prioritized. The first base station may determine that an activation condition has been met. The first base station may send an activation request message to a second base station based on the activation condition being met. The first base station may receive an activation response message from the second base station, the activation response message indicating that the first base station activates WTRU capabilities (e.g., a portion of the first base station that is capable of establishing a Uu link).

[0010] The mobility management signaling may be part of a mobility management signaling exchange. The mobility management signaling exchange may be associated with transitioning a wireless transmit / receive unit (WTRU) from a second base station to a first base station. Upon completion of the mobility management signaling exchange, the first base station may receive a deactivation command from the second base station. Based on the deactivation command, the first base station may deactivate WTRU capabilities (e.g., a portion of the first base station that is capable of establishing a Uu link).

[0011] The first base station may determine that the satellite position is within a distance threshold from the location. In response to determining that the satellite position is within the distance threshold from the location, the first base station may deactivate WTRU capabilities (eg, the portion of the first base station capable of establishing a Uu link).

[0012] The processor may be configured to establish a Uu interface for inter-gNB communication. The processor may be configured to tunnel Xn interface information through the Uu interface. For example, the Xn interface information may be tunneled through the UE side of the first gNB or the second gNB.

[0013] For example, inter-gNB communication may include communication between a first gNB and a second gNB. A Uu interface may be established via a satellite link. The satellite link may include a first gateway, a satellite, and / or a second gateway. The first gateway may be in radio communication with the first gNB. The second gateway may be in radio communication with the second gNB.

[0014] The processor may be further configured to establish a cell for a second gNB. For example, the cell may be dedicated to inter-gNB communications. For example, the cell may be established to prioritize inter-gNB communications. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Additionally, like reference numerals in the drawings indicate like elements.

[0016] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0017] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system.

[0018] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within the illustrated communication system.

[0019] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of another example RAN and another example CN for use within the illustrated communication system.

[0020] Figure 2 is a system diagram illustrating a non-terrestrial network (NTN) in which one or more disclosed embodiments may be implemented.

[0021] Figure 3A is a block diagram illustrating an example user plane (UP) protocol stack.

[0022] Figure 3B is a block diagram illustrating an example control plane (CP) protocol stack.

[0023] FIG. 4A to FIG. 4C is a system diagram illustrating an example soft feeder link switching process.

[0024] Figure 5A and Figure 5B is a call flow diagram illustrating example signaling during a handover process.

[0025] Figure 6is a block diagram illustrating an example Xn-user plane (Xn-U) protocol stack and an example Xn-control plane (Xn-C) protocol stack.

[0026] Figure 7 is a block diagram illustrating the establishment of a dedicated cell for inter-gNB signaling.

[0027] Figure 8 is a block diagram illustrating a gNB using dedicated resources to access a cell shared by other devices.

[0028] Fig. 9 is an illustrative protocol stack over a Uu based Xn interface that demonstrates WTRU capabilities (e.g., UE side) via a gNB.

[0029] Fig. 10A and Fig. 10B is a call flow diagram illustrating the setup process for WTRU capabilities (e.g., UE side) for gNB.

[0030] Fig.11A and Fig. 11B is a call flow diagram illustrating a conditional WTRU capability (eg, UE side) setup procedure with conditional configuration.

[0031] Fig.12 is a timing diagram showing an example of periodic activation and deactivation of WTRU capabilities (e.g., UE side) of a gNB.

[0032] FIG. 13A to FIG. 13D is a system diagram showing the soft feeder switching process using inter-gNB signaling on the Uu interface.

[0033] Fig.14 It is shown in FIG. 13A to FIG. 13D A call flow diagram of example signaling during a soft feeder switching process is shown in FIG. DETAILED DESCRIPTION

[0034] Figure 1A1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0035] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the UE 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include a user equipment (WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0036] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0037] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

[0038] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0039] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

[0040] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0041] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0042] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0043] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0044] Figure 1A The base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0045] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text and video, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0046] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0047] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0048] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0049] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0050] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV, or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0051] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0052] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0053] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0054] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0055] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0056] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

[0057] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0058] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0059] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0060] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0061] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0062] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0063] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during an inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0064] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0065] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0066] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0067] In a representative embodiment, the other network 112 may be a WLAN.

[0068] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0069] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0070] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0071] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0072] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0073] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

[0074] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0075] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0076] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0077] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0078] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0079] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b and routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0080] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0081] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0082] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0083] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring, etc.

[0084] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0085] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0086] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0087] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0088] like Figure 2 As shown, several radio interfaces may be established in the NTN. For example, a feeder link may refer to a wireless link between a satellite and a gateway. A service link may refer to a radio link between a satellite and a WTRU. An inter-satellite link (ISL) may refer to a transmission link between satellites. The ISL may be supported by a regenerative payload. The ISL may be implemented using a radio or optical interface (e.g., a 3GPP radio or a dedicated optical interface).

[0089] Different interfaces can be used for each radio link. Different interfaces can depend on the satellite payload configuration. For example, for transparent payload, NR-Uu radio interface can be used for service link. In transparent payload, NR-Uu radio interface can be used for feeder link. For regenerative payload, NR-Uu interface can be used for service link. For reserved payload, satellite radio interface (SRI) can be used for feeder link.

[0090] Figure 3A An example user plane (UP) protocol stack for transparent payload configuration is shown. Figure 3BAn example control plane (CP) protocol stack for transparent payload configuration is shown. As shown, the two protocol stacks may include a radio link control (RLC) layer below a packet data convergence protocol (PDCP) layer, a media access control (MAC) layer below the RLC layer, and a physical (PHY) layer below the MAC layer. The UP protocol stack may also include a service data adaptation protocol (SDAP) layer above the PDCP layer. The SDAP layer may perform functions such as mapping between quality of service (QoS) stream bearers to data radio bearers and / or marking QoS stream identifiers in data packets. The CP protocol stack may include a radio resource control (RRC) layer above the PDCP layer. The RRC layer may perform functions such as inter-RAT mobility and / or mobility functions (e.g., handover, context transfer).

[0091] NTN satellites can support multiple cells. Each cell may include one or more satellite beams. Satellite beams can cover a coverage area on the earth (e.g., like a terrestrial cell). Satellite beams can vary in diameter. For example, in LEO deployments, satellite beams can be in the range of 100km to 1000km. The beam coverage area in LEO deployments may change over time due to satellite movement. In GEO deployments, the diameter range of satellite beams can be 200km to 3500km. The beam coverage area in GEO deployments can remain fixed relative to the earth. Beam movement can be classified as "earth mobile" (e.g., in LEO deployments, where the beams continuously move across the earth). Beam movement can be classified as "earth fixed" (e.g., in GEO deployments, beams are steered to maintain coverage of a fixed position until a new cell surpasses the coverage area).

[0092] The round trip time (RTT) and maximum differential delay of NTN may be greater than that of terrestrial systems. This may be due to the altitude and beam diameter of the NTN platform. For example, in a transparent NTN deployment, the RTT may range from 25.77 milliseconds (e.g., for a LEO deployment at an altitude of 600 km) to 541.46 milliseconds (e.g., for a GEO deployment). The maximum differential delay in a transparent NTN deployment may range from 3.12 milliseconds to 10.3 milliseconds.

[0093] The RTT for the transparent configuration may depend on the serving and feeder links. The RTT of the regenerated payload may depend on the serving link (e.g., only on the serving link). The RTT of the regenerated payload may be approximately half of the RTT of the transparent payload. Prior to initial access, the WTRU may perform timing pre-compensation. This may help minimize (or at least reduce) the impact on existing NR systems (e.g., by avoiding preamble ambiguity or timing the receive window appropriately).

[0094] As part of timing pre-compensation, the WTRU may obtain its position via GNSS. The WTRU may obtain a feeder link delay (or common delay). The WTRU may obtain a satellite position (e.g., via satellite ephemeris data). The satellite ephemeris data may be broadcast (e.g., periodically) in system information. The satellite ephemeris data may include the speed, direction, and / or velocity of the satellite. The WTRU may estimate the distance to the satellite and / or the delay relative to the satellite. The WTRU may add a feeder link delay component to the estimated delay to obtain the complete WTRU to gNB RTT. The complete WTRU to gNB RTT may be used to offset communication timing (e.g., timers, receive windows, and / or timing relationships). The network may perform frequency compensation.

[0095] In NTN, the difference in reference signal received power (RSRP) between the cell center and the cell edge may not be as significant as in terrestrial systems. There may be larger areas of cell overlap in NTN compared to terrestrial systems. Measurement-based mobility may become less reliable in NTN environments. NTN may utilize conditional handover and / or measurement report triggering that depends on location and / or time. Enhanced mobility techniques may be of particular interest in LEO deployments. For example, in LEO deployments, even a stationary WTRU may be expected to perform mobility approximately once every 7 seconds due to satellite movement. The frequency of mobility checks may depend on deployment characteristics.

[0096] In non-geostationary orbit (NGSO) deployments (e.g., LEO, MEO), there may be a switching point when the satellite is moving at high altitude. The switching point may indicate that the satellite has moved far enough away from the geographic location of the land-based gateway that the feeder link may no longer be suitable (e.g., due to the curvature of the earth). At the switching point (e.g., sometimes called a feeder link switching point), the satellite may undergo a feeder link switch. A feeder link switch may allow the satellite to terminate the feeder link with the previous gateway. During a feeder link switch, the satellite may establish a new feeder link with the input gateway. Types of feeder link switches may include hard switches and soft switches.

[0097] In a hard feeder link handover, a new feeder link from the satellite to the input gateway may be established after the feeder link with the previous gateway has been cut. A hard feeder link handover may cause service continuity issues due to the disappearance of cells associated with the previous gNB associated with the previous gateway. A hard feeder link handover may cause high signaling overhead due to large-scale random accesses to the input gNBs associated with the input gateways.

[0098] FIG. 4A to FIG. 4CA soft feeder link handover is shown. In a soft feeder link handover, there is a temporary period during which the satellite supports multiple feeder links to the previous gateway and to the input gateway simultaneously. This enables the satellite to broadcast cells associated with both gateways and their associated gNBs for a temporary period prior to the feeder link handover. In a soft feeder link handover, the WTRU served by the satellite may gradually transition to the new gNB associated with the input gateway. The transition may be further facilitated by biasing the measurement thresholds of cells associated with neighboring cells. The transition may be accomplished via a conditional handover based on time and / or location. These techniques reduce the instantaneous signaling load associated with random access to the input cell. These techniques also help mitigate service continuity issues.

[0099] For example, Figure 4A As shown, at time T1, the satellite (labeled "SAT") may have a feeder link connection with gNB1 and may be close to the feeder link switching point between gNB1 and gNB2. Figure 4B As shown in Figure 2, the satellite can reach the feeder link switching point. At T2, the satellite can have feeder link connections with gNB1 and gNB2. Figure 4C As shown, at time T3, the satellite may have passed the feeder link switching point. At time T3, the satellite may maintain the feeder link connection with gNB2 and end the feeder link connection with gNB1.

[0100] A terrestrial connection is available between a gNB associated with the former and an input gateway. The terrestrial connection may be used to establish an Xn interface between gNBs. Over the Xn interface, the gNBs may exchange WTRU mobility signaling. For example, the gNBs may exchange WTRU context information, as described in more detail below.

[0101] Cell-level mobility in NR may use RRC signaling (e.g., explicit RRC signaling). For example, the source gNB may indicate the current serving cell and the target gNB may indicate the cell to which the WTRU is to transition.

[0102] Figure 5A and Figure 5B The inter-gNB mobility (e.g., handover) process is shown. As shown, user data may be transferred between multiple devices (e.g., WTRU, source gNB, and user plane function (UPF)). At 0, the source gNB may receive mobility control information from the access and mobility management function (AMF). The source gNB may have WTRU context information. The WTRU context information may provide information about roaming and access restrictions. Roaming and access restrictions may be provided at connection establishment or at the last timing advance (TA) update.

[0103] At 1, the source gNB may configure the WTRU measurement procedures (e.g., measurement objects, reporting events). The WTRU may report according to the measurement configuration. The measurement reports may be periodic or may be triggered based on events. For example, such an event may involve neighbor cell measurements exceeding a threshold (e.g., an absolute threshold or a relative threshold compared to the serving cell). Based on the measurement reports and other radio resource management (RRM) information, the source gNB may decide to hand over the WTRU.

[0104] At 2, the source gNB may decide to handover the WTRU. The handover decision may be made based on measurements received from the WTRU. At 3, the source gNB may issue a handover request message to the target gNB by passing a transparent radio resource control (RRC) container with information that may be used to prepare the handover at the target gNB. For example, the information may include at least the target cell identifier, a key (e.g., KgNB*), the cell radio network temporary identifier (C-RNTI) of the WTRU in the source gNB, the RRM configuration including the WTRU inactive time, the basic access stratum (AS) configuration including antenna information and downlink (DL) carrier frequency, the current quality of service (QoS) flow to data radio bearer (DRB) mapping rules applied to the WTRU, the system information block 1 (SIB1) from the source gNB, the WTRU capabilities for different radio access technologies (RATs), protocol data unit (PDU) session related information, etc. The information may include measurement information reported by the WTRU, including beam related information (if available). The PDU session related information may include slice information and one or more QoS profiles for the QoS flow level.

[0105] At 4, admission control may be performed by the target gNB to determine whether the WTRU may be admitted. The target gNB may prepare resources for the handover. For example, the target gNB may prepare resources for the handover based on determining that the WTRU may be admitted. At 5, the target gNB may send an acknowledgment of the handover request (e.g., a handover request acknowledgment) to the source gNB. The acknowledgment may include a handover command (e.g., an RRC reconfiguration message). The handover command may be in a transparent container to be sent to the WTRU. The handover command may be sent via control signaling (e.g., RRC signaling).

[0106] If the source gNB receives an acknowledgment of the handover request, or if a transmission of a handover command is initiated in the DL towards the WTRU, data forwarding from the source gNB to the target gNB may be initiated. For example, at 6, a RAN handover may be initiated at the source gNB. The source gNB may trigger the handover by forwarding the handover command to the WTRU. The handover command may include information that may be used to access the target cell. For example, the handover command may include a target cell identifier, a new C-RNTI, and / or a target gNB security algorithm identifier for a selected security algorithm. The handover command may include a set of dedicated random access channel (RACH) resources, an association between RACH resources and synchronization signals / PBCH blocks (SSBs), an association between RACH resources and WTRU-specific channel state information reference signal (CSI-RS) configurations, common RACH resources, system information of the target cell, and the like.

[0107] The source gNB may deliver buffered data and new data from the UPF. At 7, the source gNB may send one or more status messages. For example, at 7a, the source gNB may send an Early State Transfer message. At 7b, the source gNB may send an SN State Transfer message to the target gNB. The status message may convey the UL Packet Data Convergence Protocol Sequence Number (PDCP SN) receiver status and / or DL ​​PDCP SN transmitter status of the DRB to which the PDCP status preservation applies (e.g., for Radio Link Control Acknowledged Mode (RLC AM)). The source gNB may also forward user data from the UPF to the target gNB (e.g., during execution of a handover procedure). The target gNB may buffer user data from the source gNB until the handover is complete.

[0108] The WTRU may detach from a source cell (e.g., associated with a source gNB). The WTRU may synchronize with a target cell. At 8, an RRC handover may be completed. For example, the handover process may be completed by the WTRU sending a message (e.g., an RRCReconfigurationComplete message) to the target gNB. The WTRU may release resources from the source gNB. If the handover is complete, the target WTRU may send a handover success message to the source gNB at 8a to notify the source gNB of the successful handover. At 8b, the source gNB may send a status message to the target gNB. The source gNB may continue to forward its received user data to the target gNB.

[0109] At 9, the target gNB may send a path switch request message to the AMF. The path switch request may switch the DL data path towards the target gNB. At 10, the AMF may switch the DL data path towards the target gNB. The UPF may send one or more end marker packets to the source gNB on the original DL path. The end marker packets may be sent using a PDU session / tunnel. The AMF and UPF may release any user plane (or transport network layer (TNL)) resources to the source gNB.

[0110] At 11, the AMF may acknowledge the Path Switch Request message by sending an acknowledgement message (e.g., Path Switch Request Acknowledgement). At 12, the target gNB may send a WTRU Context Release message to the source gNB. The target gNB may send a WTRU Context Release message in response to receiving the acknowledgement message from the AMF. The WTRU Context Release message may be used to notify the source gNB of the success of the handover. The source gNB may release the radio and control plane related resources associated with the WTRU context. Any ongoing data forwarding may continue.

[0111] The Xn interface may be used between two NG-RAN nodes (e.g., gNBs). Figure 6 As shown, the Xn interface may include an Xn user plane (UP) (in Figure 6 ) and the Xn control plane (CP) (shown on the left hand side of Figure 6 ). As shown in the figure, the UP transport network layer may include an Internet Protocol (IP) layer. The UP transport network layer may include a General Packet Radio Service (GPRS) Tunneling Protocol User Plane (GTP-U) on top of the IP layer. The UP transport network layer may include a User Datagram Protocol (UDP) to communicate with the UP power distribution unit. The Xn UP may provide non-guaranteed delivery of the UP power distribution unit. The Xn UP may support data forwarding and flow control.

[0112] The CP transport network layer may include a stream control transmission protocol (SCTP) on top of the IP layer. The SCTP layer may deliver application layer messages. Transport IP layer point-to-point transport may be used to deliver signaling to the power distribution unit. The Xn CU interface may support Xn interface management, WTRU mobility management (including context transfer and RAN paging), and / or dual connectivity. The Xn-AP interface may be established via the transmission of an Xn setup request message (e.g., XNSetupRequest) from the source gNB to the target gNB. The target gNB may confirm the setup (e.g., by responding with an XNSetupResponse message).

[0113] In an example, the gNB may use the Xn interface to formulate certain network operations. Xn interface information may be transmitted via the Xn interface. For example, the gNB may transmit Xn interface information via the Xn interface. For example, the gNB may transmit Xn interface information via the Xn interface to formulate network operations. For example, the gNB may transmit Xn interface information via the Xn interface to perform handover and / or enable dual connectivity. The Xn interface information may include any information transmitted via the Xn interface. For example, the Xn interface information may include WTRU context information transmitted via the Xn interface. The WTRU context information may be used to perform handover.

[0114] A physical, land-based connection may exist between a previous gNB (e.g., source gNB) and an input gNB (e.g., target gNB). The gNB may use this connection to perform a feeder link handover. The connection may be used to establish an interface between gNBs (e.g., Xn interface). The Xn interface may be used to exchange relevant mobility signaling between gNBs. For example, mobility signaling may allow a WTRU to transition from one gNB to another gNB prior to a feeder link handover.

[0115] The previous gNB and the input gNB may be located in different cities, countries, and / or continents. The previous gNB and the input gNB may also belong to different network providers. There may be no physical link between the two gNBs. In addition, switching a WTRU served by a satellite during the transition period before the feeder link switch may result in a large signaling load. Even if there is a physical link between the previous gNB and the input gNB, the physical link will have to have sufficient throughput and latency characteristics to cope with the large-scale and time-critical signaling load.

[0116] For example, the physical link between the previous gNB and the incoming gNB may lack adequate throughput characteristics. Lack of adequate throughput characteristics may increase the risk of prolonged service interruption. For example, service interruption may increase due to the WTRU performing initial access and / or core network re-registration to the incoming gNB. Signaling storms due to lack of coordination between gNBs may increase service interruption. Service interruption may occur periodically when subsequent satellites in orbit undergo the same feeder link switch.

[0117] Inter-gNB communications (e.g., inter-gNB signaling) may be transmitted over the air. For example, inter-gNB signaling may be transmitted over a Uu interface. A satellite (e.g., a satellite communicating with two gNBs) may forward information from a previous gNB to an incoming gNB. For example, a satellite may forward information via a feeder link. For example, a satellite may forward information via a backhaul link. A radio link between gNBs via a satellite may be referred to as a satellite link.

[0118] The Uu interface may enable communication of certain information. For example, the Uu interface (e.g., radio interface) may enable communication between a WTRU and a gNB (or a gNB distributed unit (DU)). The Uu interface may include a physical layer, a data link layer, and / or a network layer. The Uu interface may provide physical channels to carry data over a radio path, and provide logical channels to carry specific types of data. There are two types of logical channels: signaling and control channels, and traffic channels.

[0119] The cellular network may be divided, where each division may be associated with a corresponding geographic area. The segments may be referred to as cells. A gNB (e.g., base station) may support one or more cells (e.g., the area a gNB may cover / serve is depicted, sometimes referred to as a cell). Each cell may be supported (e.g., served) by a gNB. A WTRU within a cell may communicate with the gNB via radio waves on a frequency channel assigned by the gNB. In some examples, a previous (e.g., source) gNB (e.g., gNB1) may create a new cell via satellite (SAT) to serve an input gNB (e.g., gNB2), such as Figure 7 As shown. A dedicated cell may be created sometime before the feeder link switch. A dedicated cell may be created when the satellite is a certain distance from the feeder link switch point. A dedicated cell may be used to establish inter-node signaling between gNB1 and gNB2. A dedicated cell may be used to establish an interface (e.g., an Xn interface) for WTRU mobility management signaling (e.g., transmitting WTRU context information).

[0120] A dedicated cell may be dedicated to the establishment of inter-gNB connections. A dedicated cell may be configured such that the intended gNB (e.g., only the intended gNB) can access the dedicated cell. For example, beam steering techniques or other cell barring mechanisms (e.g., reserved resources, cell barring bits, or reserved PLMNs) may be used to ensure that only the intended gNB can access the dedicated cell. A dedicated cell may be treated separately from other cells broadcast by a satellite. For example, a dedicated cell may not include WTRU assistance information (e.g., satellite coverage area information or neighboring cell reference points).

[0121] like Figure 8As shown, the cell used for establishment of inter-gNB signaling may not be a dedicated cell used only for inter-gNB signaling. For example, the cell may be a normal NTN cell. In this case, inter-base station communications may be prioritized on the cell (e.g., the gNB attempting to establish an inter-gNB communication interface may have reserved and / or prioritized access to the cell). For example, the WTRU side of the gNB accessing the cell to establish an interface for inter-gNB signaling may use dedicated air interface resources to establish the interface. For example, the WTRU side of the gNB may use resources dedicated to inter-base station communications to initiate a RACH process. The dedicated air interface resources may be different from the resources used and / or available to conventional WTRUs accessing the cell. The WTRU side of the gNB may be the mobile terminal (MT) side of the gNB, or any other component of the gNB capable of performing one or more WTRU capabilities (e.g., tasks typically performed by a WTRU, such as communicating via a Uu interface).

[0122] The WTRU side of an incoming gNB (e.g., gNB2) may distinguish itself from a conventional WTRU. For example, the WTRU side of an incoming gNB may distinguish itself by using one or more of the following to access a cell: a dedicated RNTI (e.g., C-RNTI), dedicated RACH resources (e.g., resources that the WTRU side may use to initiate a RACH procedure, such as a dedicated preamble, RACH timing, etc.), dedicated channel resources (e.g., time / frequency resources), a cell barring mechanism (e.g., a cell barring bit indicating that the cell is barred for one or more other network devices), a reserved PLMN, and / or a dedicated unified access control (UAC) category.

[0123] The incoming gNB may have WTRU receive and transmit capabilities. The incoming gNB may use the capability to communicate with the previous gNB. For example, the incoming gNB may access a cell (e.g., a cell dedicated to inter-gNB signaling or a cell shared with other devices) in the same manner as the WTRU. For example, the WTRU side of the incoming gNB may perform one or more of: connection setup / (re)establishment (e.g., such as cell synchronization), time / frequency pre-compensation, measurements (e.g., SSB / CSI-RS), and / or random access specified for the WTRU.

[0124] If the connection establishment from the WTRU side of the incoming gNB to the previous gNB is successful, higher layer protocols (e.g., Xn-AP, SCTP, IP, etc.) may be established between the previous gNB and the gNB side of the incoming gNB. The WTRU side of the incoming gNB may forward all incoming higher layer signaling to the gNB side (e.g., based on the message header). Thus, a signaling interface for performing WTRU mobility management between gNBs may be established.

[0125] Fig. 9 An exemplary protocol stack demonstrating the Xn interface over Uu on the WTRU side via a gNB (e.g., gNB2) is shown. Fig. 9 Each of the gNBs is shown as accessing the satellite via a gateway, but one or both of the gNBs may access the satellite without using a gateway.

[0126] The WTRU side of the gNB may be enabled / activated or disabled / deactivated continuously, periodically or conditionally.

[0127] If the WTRU side of the gNB is enabled, the WTRU side may act as a WTRU (e.g., perform operations specified for the current RRC connection state, such as RRC idle / inactive / connected). If the WTRU side of the gNB is disabled, the WTRU side may suspend one or more operations. For example, the WTRU side of the gNB may disable operations performed in the RRC state (e.g., paging reception and / or measurement).

[0128] Fig. 10A and Fig. 10B An exemplary setup of the WTRU side of the gNB is shown. As shown, the deactivated WTRU side of the gNB may send an activation request message (e.g., a UESetupRequest message or a UEActivationRequest message) to initiate the setup / activation process.

[0129] The activation request message may be sent to the gNB side of the same gNB, to the core network, or to another network node (e.g., a network node where a higher layer interface is to be established for the purpose of mobility management signaling exchange).

[0130] The activation request message may be transmitted via control signaling. For example, the activation request message may be transmitted via radio resource control (RRC) signaling or a medium access control (MAC) control element (CE). The activation request message may be sent during a random access procedure (e.g., via msgA, msg3, or msg5), via dedicated resources (e.g., stored grants, configured grant occasions, or periodically reserved resources for WTRU activation), and / or using previously provided resources (e.g., resources provided when the WTRU is deactivated).

[0131] The activation request message may be sent periodically. The activation request message may be sent in response to an activation trigger. For example, the WTRU side may determine that the activation condition has been met. Based on the activation condition being met, the WTRU side may send an activation request message to another gNB. The activation trigger may be an event indicating that the gNB should attempt to establish an Xn interface with another gNB. For example, activation may be triggered by one or more of the following: receiving an explicit indication (e.g., from the gNB side of the gNB), receiving a pay signal (e.g., from a gNB attempting to establish an inter-gNB signaling interface), satisfying one or more trigger conditions (e.g., a satellite passing through a feeder link switching point or arriving within a threshold distance of a feeder link switching point). For example, a marker bit may be present in paging signaling to indicate that a triggering event has occurred.

[0132] The WTRU side of the gNB may monitor response messages (e.g., UEActivation or UESetup messages). For example, the WTRU side of the gNB may monitor response messages based on the transmission of an activation request message. The WTRU side may monitor indefinitely, or subject to a monitoring window (e.g., UESetupResponseWindow). The monitoring window may start immediately (e.g., at / in the transmission of the first symbol following the transmission of the activation request message). The WTRU side may be configured to start the monitoring window after an offset (e.g., a fixed offset provided by the network, or an offset calculated by the WTRU such as RTT).

[0133] The WTRU may monitor (e.g., via PDCCH) an activation response message (e.g., a network response to an activation request message). The WTRU may monitor the network response while the monitoring window is open. The WTRU may stop a timer associated with the monitoring window. The WTRU may receive an activation response message. The WTRU may stop a timer associated with the monitoring window based on receiving the network response message. The WTRU may stop monitoring for a response. The WTRU may stop monitoring for a response based on receipt of a network response.

[0134] The activation response message may instruct the base station to activate one or more WTRU capabilities (e.g., instruct the WTRU side to activate the portion of the base station that is capable of establishing a Uu link, e.g., to start WTRU side setup / activation). The response message may be a response to an activation request message (e.g., Fig. 10A The response message may be a direct indication from the gNB side of the gNB (e.g., as shown in Fig. 10B shown).

[0135] The response message may include one or more of the following fields: the time to activate the WTRU side (e.g., 10:00:35 UTC, the incremental time since the response message was received, etc.), an indication to perform connection establishment (e.g., a flag indicating that the WTRU side should attempt connection establishment as soon as possible, or at some time in the future), information about the expected cell of the source gNB and the resources to be used at the cell, an indication to resume the suspended WTRU side action (e.g., activating and / or providing a configuration to enable one or more of the following: paging reception, measurement, cell (re)selection, etc.), etc. For example, the information about the intended cell may include one or more of: a dedicated set of resources in which to access the network (e.g., dedicated RACH resources, RACH timing, reserved preambles, RNTIs, and / or time / frequency resources), time and / or frequency synchronization information (e.g., satellite assistance / ephemeris information), a public land mobile network (PLMN) identifier of the intended cell of the source gNB, a cell identifier of the intended cell, a set of resources on which measurements are to be performed, a measurement configuration for cell synchronization (e.g., a set of SSB or CSI-RS resources), and / or activation of paging reception (e.g., the WTRU may receive a paging cycle configuration (such as a RAN or CN paging cycle configuration), and a paging RNTI to start paging monitoring).

[0136] When the response message is received, the WTRU side may perform one or more operations. For example, the WTRU side may restore previously deactivated operations on the WTRU side, apply configuration (e.g., indicated, provided, or default configuration), start monitoring paging (e.g., monitoring PDCCH during a provided or default paging cycle via an assigned paging RNTI), perform cell synchronization (e.g., perform measurements, apply time-frequency precompensation using satellite ephemeris data), perform connection establishment (e.g., as indicated in the response message), and / or set up a tunnel to the gNB side. Performing the connection establishment may be conditional on the information provided in the response message (e.g., the connection establishment may be performed at a dedicated time, using indicated resources, and / or to an indicated cell or PLMN).

[0137] like Fig. 10B As shown, the WTRU side may be activated directly (e.g., without prior transmission of an activation request message). For example, the WTRU side may be activated upon receipt of an activation message (e.g., UEActivation or UESetup). The activation message may be received from the gNB side of the gNB. The activation message may be sent in response to a paging message and / or a setup message from another gNB (e.g., a gNB attempting to establish an inter-gNB signaling interface) or from the core network.

[0138] The gNB side of the gNB may be the receiving entity of the activation message. For example, upon receiving the activation message on the gNB side, the gNB may activate and / or establish the WTRU side.

[0139] The WTRU side may send an acknowledgement (e.g., UESetupComplete) of successful WTRU setup. For example, the WTRU side may send an acknowledgement (e.g., UESetupComplete) of successful WTRU setup based on successful receipt of the activation message and / or successful implementation of corresponding actions (e.g., according to the default setup procedure or as directly indicated in the activation message). For example, the WTRU side may send the acknowledgement to the gNB side, the core network, or other gNBs from which the WTRU side received the activation message.

[0140] The WTRU side may receive an explicit indication to deactivate the WTRU side functionality. For example, upon connection release, the WTRU side may receive a deactivation message.

[0141] The WTRU side may receive a deactivation message in response to a connection setup / resumption message (e.g., RRCSetup and / or RRCResume, respectively). For example, the WTRU may receive a UEDeactivation message. The UEDeactivation message may include, for example, one or more of the following fields: an identifier on the WTRU side (e.g., C-RNTI), an indication to discard one or more stored configurations (e.g., RRC configurations), an indication to maintain one or more stored configurations, and an indication to stop and / or reset timers and / or counters, an indication to release established protocol layers and / or interfaces (e.g., terminate any Xn-AP, IP, GTP-U, SCTP sessions), an indication to flush one or more hybrid automatic repeat request (HARQ) buffers, an indication to suspend uplink (UL) transmission (e.g., dynamic UL grants, configured grants, random access messages, HARQ / ARQ retransmissions, etc.), an indication to suspend DL reception (e.g., DL allocations, semi-persistent scheduling, random access messages, etc.), one or more RRC idle / inactive processes to be suspended (e.g., suspending one or more of RAN / CN-derived paging, measurements, cell (re)selection, etc.), and / or one or more resources or resource ranges (e.g., time, frequency and / or space) in which WTRU-side deactivation is to be applied.

[0142] The WTRU side may receive a UEDeactivationwithActivationSuspend message. The UEDeactivationwithActivationSuspend message may include one or more fields, a set of resources in which the deactivation / suspend action is to be applied (e.g., the WTRU side may apply the deactivation / suspend action until 10:00:35 UTC time, or for the next "X" time units), and / or one or more conditions set by the initiating WTRU side.

[0143] The WTRU side may perform one or more actions (e.g., one or more of the actions listed herein) upon receiving the deactivation message. The deactivation message may be received via control signaling (e.g., RRC signaling or MAC CE) and may originate from a network node, another network node, or the gNB side of the core network.

[0144] The WTRU side activation / setup may be performed based on the satisfaction of one or more conditional activation criteria (e.g., conditional configuration). The conditional activation criteria may be provided by the gNB side of the gNB or another gNB. The conditional activation criteria may be provided via a conditional configuration message (e.g., UESetupConditionalConfiguration), such as Fig.11A and Fig. 11B As shown in .

[0145] The conditional configuration message may be received via control signaling (eg, RRC signaling or MAC CE). The conditional configuration message may include one or more of the following information fields: a conditional configuration to be applied when a trigger condition is met (e.g., a paging configuration, a RACH configuration, and / or a measurement configuration), a trigger condition for activating the conditional configuration and / or the WTRU side set (e.g., a time condition, a periodicity condition, a location condition), a dedicated set of resources in which to access the network (e.g., dedicated RACH resources, RACH timing, a reserved preamble, an RNTI, or time and / or frequency resources), time and / or frequency synchronization information (e.g., satellite ephemeris information), a PLMN identifier, a cell identifier, a duration for maintaining and / or storing the configuration and / or trigger conditions (e.g., the time or set of resources to maintain the configuration and / or conditions), a flag indicating that the information is an incremental change in a set of configuration and / or trigger conditions (e.g., indicated in a previous conditional configuration message or a default configuration), an indication for deleting one or more previously stored configurations and / or trigger conditions, an indication for maintaining one or more previously stored and / or received configurations and / or trigger conditions, and / or an index to a stored or preconfigured configuration and / or trigger condition.

[0146] The WTRU side may store the received configuration and / or trigger condition. For example, the WTRU side may store the received configuration and / or trigger condition based on receiving the conditional configuration message. For example, the WTRU side may store this information for the duration of its operation. The WTRU may store the information for a limited period of time (e.g., until "X" time, for a period of "Y" time units, or for a period of "Z" resources). The WTRU side may then evaluate the trigger condition.

[0147] The WTRU side may receive a subsequent conditional configuration message with a different set of configuration and / or trigger conditions than the original conditional configuration message. The WTRU side may perform one or more of the following actions: delete any previously stored configuration and / or trigger conditions, replace the configuration / trigger conditions with updated values ​​provided in the subsequent message, apply incremental changes to the previously stored set of configuration and / or trigger conditions, apply incremental changes to the default configuration, maintain one or more previous configurations and / or trigger conditions, and store new configurations and / or trigger conditions. The WTRU side may perform the one or more actions based on the indication in the conditional configuration message.

[0148]

[00136] One or more of the information fields, configurations and / or triggering conditions for conditional WTRU setup may be provided by the gNB side or another network node. For example, the information field may be provided at the WTRU side at deactivation. For example, the information field may be included in the UEDeactivationwithActivationSuspend message. This information field may be provided along with any other information fields as described above.

[0149] The trigger conditions described herein may be used to trigger an RRC state transition on the WTRU side. For example, the trigger condition may be used to trigger a transition from an RRC_IDLE or RRC_INACTIVE WTRU mode to an RRC_CONNECTED mode. For example, the transition may be triggered via a trigger transmission (e.g., RRCSetup or RRCResume). The trigger conditions described herein may be used to trigger a WTRU side request to perform a WTRU setup (e.g., via the transmission of a UESetupRequest message), as described herein.

[0150] like Fig.12As shown, the WTRU side may be activated periodically. For example, the WTRU side may be activated periodically to coincide with the timing of feeder link switching performed by successive satellites in orbit. The WTRU side may receive a series of times at which to perform WTRU side setup (e.g., via the sending of UESetupRequest), activate WTRU side functionality (e.g., apply one or more configurations), and / or perform connection establishment (e.g., via the sending of RRCSetupRequest / RRCResumeRequest or via random access).

[0151] The WTRU side may be provided / configured with a time (e.g., UTC 10:00:32). In some examples, the WTRU side may be provided / configured with a fixed timing offset (e.g., 5 minutes or X frames). The activation / connection / handover conditions may be satisfied by a time associated with the satellite fix within a fixed offset from a time associated with the satellite fix passing through the location (e.g., a feeder link switching point). For example, the WTRU side may perform one or more of the following at each time equal to the original time + X*offset: WTRU side setup (e.g., via the sending of UESetupRequest), WTRU side activation (e.g., applying one or more configurations), and / or connection establishment (e.g., via the sending of RRCSetupRequest / RRCResumeRequest or random access), where X may be a configurable numeric value (e.g., an integer).

[0152] The WTRU side may periodically deactivate using one or more of the techniques described herein.

[0153] Different trigger conditions may instruct the gNB to activate the WTRU side or to establish a connection to another gNB. For example, the WTRU side may be configured with one or more of the following trigger conditions and / or provided with thresholds based on one or more of: position (e.g., of a satellite), time (e.g., 10:00:35 UTC), distance of the satellite from a reference point (e.g., distance between the satellite and a feeder link switching point), distance between the gNB and the satellite, distance between the WTRU side and the satellite, distance between the gNB (or WTRU side) and a reference point (e.g., center of a cell), distance between the gNB (or WTRU side) and an edge of the coverage area of ​​the satellite, time range (e.g., activation between 10:00:35 UTC and 10:00:40 UTC), and / or reference signal received power (RSRP) or reference signal received quality (RSRQ) of a cell.

[0154] The WTRU side may monitor whether the triggering condition is met. For example, the monitoring may be continuous or periodic. The monitoring may start after the WTRU side is configured with one or more triggering conditions.

[0155] The WTRU side may perform one or more of the following: initiating WTRU setup (e.g., via the sending of UESetupRequest), activating the WTRU side (e.g., applying one or more configurations), and / or performing connection establishment (e.g., via the sending of RRCSetupRequest / RRCResumeRequest or random access). For example, the WTRU side may perform one or more of these operations (e.g., connection establishment, WTRU side activation, etc.) based on the satisfaction of one or more of the configured trigger conditions. For example, a first (e.g., target) base station (e.g., gNB) with an activated WTRU side may determine that a handover condition associated with satellite positioning relative to a certain location (e.g., a feeder link switching point) has been met. The first base station may perform a connection establishment between the first base station and a second base station (e.g., a second gNB). For example, the first base station may initiate a random access channel (RACH) procedure with the second base station based on the handover condition being met. The first base station may establish a Uu link between the first base station and the second base station. The Uu link may be established via a satellite link.

[0156] The WTRU side may conditionally deactivate using any of the techniques described herein.

[0157] If the WTRU side of the gNB is disabled, the WTRU side may not perform WTRU actions (e.g., equivalent to a legacy WTRU that is powered off). If the WTRU side of the gNB is disabled, the WTRU side may be operating in RRC_IDLE mode or RRC_INACTIVE mode. For example, when disabled, the WTRU side may be performing normal IDLE / INACTIVE mode WTRU actions. For example, the WTRU side may perform traditional IDLE / INACTIVE cell selection / reselection. The WTRU side may be configured with information for prioritizing the expected cell (e.g., provided by the source gNB). The priority information may include a physical cell identifier (PCI), frequency, etc. For example, if the WTRU side detects the expected cell (e.g., signaling associated with the expected cell), the WTRU side may perform cell reselection for the cell. Cell reselection may be constrained by the signal level quality of the detected cell (e.g., based on an absolute threshold, a relative threshold to the current serving cell, etc.). The WTRU side may receive auxiliary information about the source cell from the gNB side (e.g., within a UESetup message).

[0158] If the WTRU side of the gNB is disabled, the WTRU side may be operating in RRC_IDLE mode or RRC_INACTIVE mode. For example, when disabled, the WTRU side may be performing a subset or modified version of the normal IDLE / INACTIVE mode actions. For example, the WTRU side may not perform cell selection or reselection (e.g., until the WTRU side has detected a specific cell). For example, the WTRU side may use PCI, frequency, etc. to detect a cell (e.g., signaling associated with the cell). Cell reselection may be constrained by the signal level quality of the detected cell (e.g., based on an absolute threshold, a relative threshold to the current serving cell, etc.).

[0159] If the WTRU side of the gNB is enabled, the WTRU side may be operating in RRC_IDLE mode or RRC_INACTIVE mode. For example, when enabled, the WTRU side may be performing a subset or modified version of normal IDLE / INACTIVE mode actions. For example, the WTRU side may be configured to trigger connection establishment / recovery when a specific cell is detected (e.g., using the PCI, frequency, etc. used to identify the expected cell from the source gNB). The established / recovered connection may be a conditional connection. For example, the connection may be constrained by the signal level quality of the detected cell (e.g., based on an absolute threshold, a relative threshold to the current serving cell, etc.).

[0160] If the WTRU side of the gNB is enabled, the WTRU side may be operating in RRC_CONNECTED mode. For example, when enabled, the WTRU side may be performing a subset or modified version of the CONNECTED mode actions. For example, the WTRU side may not actively monitor the PDCCH of the current serving cell (for example, if the current serving cell is not the expected cell from the source gNB). The WTRU side may continue to perform neighboring cell measurements. The WTRU side may start a connection with the expected cell. The connection may be established when the WTRU side detects the expected cell (for example, detects signaling associated with the cell). The WTRU side may start the connection by performing an RRC reestablishment procedure for the expected cell. The reestablishment may be subject to the signal level quality of the detected cell (for example, based on an absolute threshold, a relative threshold to the current serving cell, etc.).

[0161] The WTRU side may start a connection with a cell by performing a cell handover (CHO) associated with the cell. The WTRU side may start a connection when an expected cell is detected.

[0162] The source gNB may initiate Xn setup towards the target gNB. The target gNB may initiate Xn setup towards the source gNB. Xn setup may be initiated after a connection with a cell is established.

[0163] Inter-gNB signaling can be sent via the NR-Uu interface. For example, FIG. 13A to FIG. 13D As shown, a dedicated cell may be created for the input gNB2. An input network node (e.g., gNB2) may be served by a cell shared with other devices (e.g., as described in relation to Figure 8 described above).

[0164] like Fig.13A As shown, at time T1, the activation / connection / handover conditions for WTRU side setup and / or connection establishment may be met. The activation / connection / handover conditions may be associated with satellite positioning relative to a certain location. For example, the activation / connection / handover conditions may be met by a satellite within a distance threshold from the location (e.g., a feeder link point). The WTRU side setup and / or connection establishment may be initiated by the WTRU side (e.g., in response to the activation / connection / handover conditions being met). The WTRU side setup and / or connection establishment may be initiated via sending a UESetupRequest to the gNB side of gNB2. A UESetupResponseWindow may be started. The WTRU side may start monitoring the PDCCH for UESetup messages.

[0165] The WTRU side may receive a UESetup message from the gNB side of gNB2. The UESetup message may indicate one or more configurations. The WTRU side may apply the indicated configurations. The WTRU side may start synchronizing with gNB1.

[0166] like Fig. 13B As shown, at time T2, the WTRU side can use the configuration indicated by the UESetup message to initiate random access to gNB1. The WTRU side can use identifiers and / or other resources to initiate random access.

[0167] The WTRU side may start relaying inter-gNB interface setup messages (e.g., XNSetupRequest messages) from gNB1 to the gNB side of gNB2. Upon successful connection establishment with gNB1, the WTRU side may start relaying messages.

[0168] like Fig. 13CAs shown, at time T3, the WTRU side may complete the inter-gNB signaling interface setup. For example, the WTRU side may complete the setup by forwarding the XNSetupResponse message to the gNB side of gNB2. gNB1 and gNB2 may begin transmitting mobility management signaling via the WTRU side of gNB2. The mobility management signaling may be part of a mobility management signaling exchange. The mobility management signaling exchange may be associated with transitioning one or more WTRUs (e.g., user equipment) from gNB1 to gNB2. The mobility management signaling may be transmitted via a Uu link (e.g., established as described herein).

[0169] Upon completion of the mobility management signaling exchange, the WTRU side of gNB2 may receive a deactivation command from gNB1. Based on the deactivation command, gNB2 may deactivate one or more WTRU capabilities (e.g., may deactivate portions of gNB2 that are capable of establishing a Uu link, e.g., the WTRU side of gNB2). For example, Fig.13D As shown, at time T4, the WTRU previously served by gNB1 may successfully move to gNB2. The WTRU side of gNB2 may receive a UEDeactivation message that terminates the WTRU side functionality of gNB2.

[0170] Fig.14 An example of the above-described signaling exchange is shown.

[0171] The WTRU side setup may be initiated by the gNB side of the input gNB. For example, Fig.14 Some of the signaling in the WTRU side setup shown can be done by referring to Fig. 10B The message exchange is replaced.

[0172] The WTRU side setup may be conditionally triggered. For example, the WTRU side setup may be triggered by a conditional configuration (e.g., provided by the gNB side of gNB2). Fig.14 The WTRU side settings shown can be Fig.11A The message exchange is replaced.

[0173] The WTRU side deactivation may be triggered by a conditional configuration (e.g. provided upon release by the gNB). For example, Fig.14 The WTRU side deactivation shown may be performed by referring to Fig. 11B For example, the WTRU side reactivation message may be replaced by a UEDeactivationwithActivationSuspend message.

[0174] Devices and techniques for inter-node mobility management are provided herein.

[0175] An example device may be a first base station, the first base station comprising a processor configured to perform one or more actions. The first base station may determine that a handover condition has been met. The handover condition may be associated with a satellite positioning relative to a certain location. The first base station may initiate a random access channel (RACH) procedure with a second base station based on the handover condition being met. The first base station may establish a Uu link between the first base station and the second base station. The Uu link may be established via a satellite link. The first base station may receive mobility management signaling from the second base station via the Uu link.

[0176] The handover condition may be satisfied by a satellite position being within a distance threshold from the location. The handover condition may be satisfied by a first time associated with a satellite position being within a fixed timing offset from a second time associated with the satellite position passing through the location. The RACH procedure may be initiated using resources dedicated to inter-base station communications.

[0177] The first base station may detect a cell dedicated to inter-base station communications (e.g., signaling associated with the cell) or a cell on which inter-base station communications are prioritized. The first base station may determine that an activation condition has been met. The first base station may send an activation request message to a second base station based on the activation condition being met. The first base station may receive an activation response message from the second base station, the activation response message indicating that the first base station activates one or more WTRU capabilities (e.g., a portion of the first base station capable of establishing a Uu link).

[0178] The mobility management signaling may be part of a mobility management signaling exchange. The mobility management signaling exchange may be associated with transitioning a wireless transmit / receive unit (WTRU) from a second base station to a first base station. Upon completion of the mobility management signaling exchange, the first base station may receive a deactivation command from the second base station. Based on the deactivation command, the first base station may deactivate one or more WTRU capabilities (e.g., a portion of the first base station that is capable of establishing a Uu link).

[0179] The first base station may determine that the satellite position is within a distance threshold from the location. In response to determining that the satellite position is within the distance threshold from the location, the first base station may deactivate one or more WTRU capabilities (eg, a portion of the first base station capable of establishing a Uu link).

[0180] The processor may be configured to establish a Uu interface for inter-gNB communication. The processor may be configured to tunnel Xn interface information through the Uu interface. For example, the Xn interface information may be tunneled through the UE side of the first gNB or the second gNB.

[0181] For example, inter-gNB communication may include communication between a first gNB and a second gNB. A Uu interface may be established via a satellite link. The satellite link may include a first gateway, a satellite, and / or a second gateway. The first gateway may be in radio communication with the first gNB. The second gateway may be in radio communication with the second gNB.

[0182] The processor may be further configured to establish a cell for a second gNB. For example, the cell may be dedicated to inter-gNB communications. For example, the cell may be established to prioritize inter-gNB communications.

[0183] Although the examples described herein have used activation / deactivation on the WTRU side of the gNB as an illustrative scenario, a person of ordinary skill in the art should understand that the examples described herein may be equally applicable to a conventional WTRU (e.g., a conventional WTRU entering / leaving discontinuous coverage or entering a power-saving state).

[0184] Although the features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without the other features and elements.

[0185] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the implementation described herein is not limited to such scenarios and is applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solution described herein is not limited to such scenarios and is also applicable to other wireless systems.

[0186] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (sent via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disk (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

[0187] It should be understood that the entity that performs the processes described herein can be a logical entity that can be implemented in the form of software (e.g., computer executable instructions) that is stored in the memory of a mobile device, network node, or computer system and executed on its processor. That is, the process can be implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device and / or a network node (such as a node or a computer system) that performs the process in question when executed by the processor of the node. It should also be understood that any sending and receiving processes shown in the figure can be performed by the communication circuit of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by it.

[0188] The various techniques described herein can be implemented in combination with hardware or software, or in a combination of the two where appropriate. Therefore, the specific implementation and device of the subject matter described herein or some aspects or parts thereof may take the form of program code (e.g., instructions), which is embodied in a tangible medium, which includes any other machine-readable storage medium, wherein when the program code is loaded into a machine (such as a computer) and executed by the machine, the machine becomes a device for practicing the subject matter described herein. In the case where the program code is stored on a medium, it is possible that the program code under consideration is stored on one or more media that jointly perform the action under consideration, that is, the one or more media together contain the code for performing the action, but in the case where there is more than one single medium, it is not required that any particular part of the code be stored on any particular medium. In the case of program code execution on a programmable device, the computing device generally includes a processor, a storage medium (including volatile and non-volatile memory and / or storage elements) readable by the processor, at least one input device, and at least one output device. One or more programs may implement or utilize the process described in conjunction with the subject matter described herein, for example, by using an API, a reusable control, etc. Such programs are preferably implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, if desired, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language and combined with a hardware implementation.

[0189] Although example embodiments may involve utilizing aspects of the subject matter described herein in the context of one or more stand-alone computing systems, the subject matter described herein is not so limited, but may be implemented in conjunction with any computing environment, such as a network or distributed computing environment. Still further, aspects of the subject matter described herein may be implemented in or across multiple processing chips or devices, and storage may similarly be affected across multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems, such as automobiles and airplanes.

[0190] In describing the preferred embodiments of the subject matter of the present disclosure as shown in the accompanying drawings, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

1. A first base station, comprising: A processor, the processor being configured to: determining that a connection establishment condition has been satisfied, wherein the connection establishment condition is associated with a satellite positioning relative to a certain location; Initiating a random access channel (RACH) procedure with the second base station based on the connection establishment condition being met; Establishing a Uu link between the first base station and the second base station, wherein the Uu link is established via a satellite link; as well as Mobility management signaling is received from the second base station via the Uu link.

2. The first base station of claim 1, wherein the connection establishment condition is satisfied by the satellite positioning being within a distance threshold from the location.

3. The first base station of claim 1, wherein the connection establishment condition is satisfied by a first time associated with the satellite position being within a fixed timing offset from a second time associated with the satellite position passing through the location.

4. The first base station according to claim 1, wherein the RACH procedure is initiated using resources dedicated to inter-base station communication.

5. The first base station of claim 1, wherein the processor is further configured to detect signaling associated with a cell, wherein the cell is dedicated to inter-base station communication or inter-base station communication is prioritized on the cell.

6. The first base station according to claim 1, wherein the processor is further configured to: Confirm that activation conditions have been met; Based on the activation condition being met, sending an activation request message to the second base station; as well as An activation response message is received from the second base station, the activation response message indicating that the first base station activates wireless transmit / receive unit (WTRU) capabilities associated with establishing the Uu link.

7. The first base station of claim 1 , wherein the mobility management signaling is part of a mobility management signaling exchange, wherein the mobility management signaling exchange is associated with switching a wireless transmit / receive unit (WTRU) from the second base station to the first base station, and wherein When the mobility management signaling exchange is completed, the processor is further configured to: receiving a deactivation command from the second base station; as well as Based on the deactivation command, WTRU capabilities associated with establishing the Uu link are deactivated.

8. The first base station according to claim 1, wherein the processor is further configured to: determining that the satellite position is within a distance threshold from the location; and In response to determining that the satellite position is within the distance threshold from the location, wireless transmit / receive unit (WTRU) capabilities associated with establishing the Uu link are activated.

9. A method performed by a first base station, the method comprising: determining that a connection establishment condition has been satisfied, wherein the connection establishment condition is associated with a satellite positioning relative to a certain location; Initiating a random access channel (RACH) procedure with the second base station based on the connection establishment condition being met; Establishing a Uu link between the first base station and the second base station, wherein the Uu link is established via a satellite link; as well as Mobility management signaling is received from the second base station via the Uu link.

10. The method of claim 9, wherein the connection establishment condition is satisfied by the satellite positioning being within a distance threshold from the location.

11. The method of claim 9, wherein the connection establishment condition is satisfied by a first time associated with the satellite fix being within a fixed timing offset from a second time associated with the satellite fix passing the location.

12. The method of claim 9, wherein the RACH procedure is initiated using resources dedicated for inter-base station communication.

13. The method of claim 9, wherein the method further comprises detecting signaling associated with a cell, wherein the cell is dedicated to inter-base station communication or inter-base station communication is prioritized on the cell.

14. The method of claim 9, wherein the mobility management signaling is part of a mobility management signaling exchange, wherein the mobility management signaling exchange is associated with switching a wireless transmit / receive unit (WTRU) from the second base station to the first base station, and wherein When the mobility management signaling exchange is completed, the method further comprises: receiving a deactivation command from the second base station; and Based on the deactivation command, WTRU capabilities associated with establishing the Uu link are deactivated.

15. The method according to claim 9, wherein the method further comprises: determining that the satellite position is within a distance threshold from the location; as well as In response to determining that the satellite position is within the distance threshold from the location, wireless transmit / receive unit (WTRU) capabilities associated with establishing the Uu link are activated.

Images