HK1249971B - Method and user terminal for satellite-to-satellite handoff in satellite communications system - Google Patents

Description

Satellite-to-satellite switching method and user terminal in satellite communication system

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and the benefit of Provisional Application No. 62/201,514, filed in the U.S. Patent and Trademark Office on August 5, 2015, and Non-Provisional Application No. 14/857,560, filed in the U.S. Patent and Trademark Office on September 17, 2015, the entire contents of which are incorporated herein by reference.

Technical Field

Various aspects described herein relate to satellite communications, and more particularly, to satellite-to-satellite handoffs for user terminals in non-geostationary satellite communications systems.

Background Art

Traditional satellite-based communication systems include a gateway and one or more satellites to relay communication signals between the gateway and one or more user terminals. A gateway is an earth station with an antenna for sending and receiving signals to and from a communication satellite. The gateway uses satellites to provide communication links connecting user terminals to other user terminals or users in other communication systems (e.g., the public switched telephone network, the Internet, and various public and/or private networks). Satellites are orbiting receivers and repeaters for relaying information.

If a user terminal is within the satellite's "footprint," the satellite can receive signals from the user terminal and transmit signals to the user terminal. A satellite's footprint is the geographic area on the Earth's surface that is within the satellite's signal range. The footprint is typically divided geographically into "beams" using one or more antennas. Each beam covers a specific geographic area within the footprint. Beams can be directed so that more than one beam from the same satellite covers the same specific geographic area.

Geosynchronous satellites have long been used for communications. Geosynchronous satellites are stationary relative to a given location on Earth, and therefore experience little time or frequency shift in the propagation of wireless signals between a communication transceiver on Earth and the geosynchronous satellite. However, because geosynchronous satellites are confined to geosynchronous orbit (GSO), the number of satellites that can be placed in GSO is limited. As an alternative to geosynchronous satellites, communication systems have been designed that utilize constellations of satellites in non-geosynchronous orbits, such as low Earth orbit (LEO), to provide communication coverage for the entire Earth, or at least a large portion of the Earth.

Compared to GSO satellite-based and terrestrial communication systems, non-geostationary satellite-based systems (e.g., LEO satellite-based systems) may present several unique challenges related to the satellite-to-satellite handover process. In particular, in order to maintain a high-quality user experience and reduce or minimize dropped calls or delays during the handover, it is desirable to minimize any disconnection of the data link during the satellite-to-satellite handover.

Summary of the Invention

Aspects of the present disclosure are directed to apparatus and methods for satellite-to-satellite handoff in a non-geostationary satellite communication system.

Aspects of the present disclosure provide a method for operating a user terminal (UT) to perform a handover operation from a first satellite to a second satellite. The UT communicates with a first gateway via the first satellite on a forward link and a return link, and the UT receives a handover message from the first gateway via the first satellite. The handover message includes information sufficient for the UT to identify the second satellite for handover and to determine a time for handover from the first satellite to the second satellite. The handover from the first satellite to the second satellite is scheduled based on the handover message, and the handover from the first satellite to the second satellite is performed.

Another aspect of the present disclosure provides a user terminal (UT) configured to perform a handover operation from a first satellite to a second satellite. The UT includes a memory having handover instructions and at least one processor operatively coupled to the memory. The processor is configured by the handover instructions to perform various operations. The processor is configured to communicate with a first gateway on a forward link and a return link via a first satellite. The processor is configured to receive a handover message from the first gateway via the first satellite, wherein the handover message includes information sufficient for the UT to identify the second satellite for handover and to determine a time for handover from the first satellite to the second satellite. The processor is configured to schedule a handover from the first satellite to the second satellite based on the handover message; and to perform a handover from the first satellite to the second satellite.

Another aspect of the present disclosure provides a user terminal (UT) configured to perform a handover operation from a first satellite to a second satellite. The UT includes means for communicating with a first gateway via the first satellite on a forward link and a return link. The UT includes means for receiving a handover message from the first gateway via the first satellite, wherein the handover message includes information sufficient for the UT to identify the second satellite for handover and to determine a time for handover from the first satellite to the second satellite. The UT includes means for scheduling the handover from the first satellite to the second satellite based on the handover message. The UT also includes means for performing the handover from the first satellite to the second satellite.

Another aspect of the present disclosure provides a non-transitory computer-readable medium comprising a plurality of instructions for causing a user terminal (UT) to perform a handover operation from a first satellite to a second satellite. The instructions cause the UT to communicate with a first gateway via the first satellite on a forward link and a return link. The instructions also cause the UT to receive a handover message from the first gateway via the first satellite, wherein the handover message includes information sufficient for the UT to identify the second satellite for handover and to determine a time for handover from the first satellite to the second satellite. The instructions also cause the UT to schedule a handover from the first satellite to the second satellite based on the handover message; and to perform a handover from the first satellite to the second satellite.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are presented to aid in the description of aspects of the disclosure and are provided solely for illustration of the aspects and not limitation thereof.

1 is a block diagram of an example communication system.

FIG2 is a block diagram of an example of the gateway of FIG1.

FIG3 is a block diagram of one example of the satellite of FIG1.

FIG. 4 is a block diagram of an example of the user terminal of FIG. 1 .

FIG. 5 is a block diagram of an example of the user equipment of FIG. 1 .

6 is a diagram of one example of a mechanically steered antenna that may be employed in the user terminal of FIG. 4 .

7 is a diagram illustrating a handover scenario involving a UT, one or more gateways, and two satellites, according to aspects of the present disclosure.

8 is a call flow diagram illustrating a first example of a satellite-to-satellite handover process according to aspects of the present disclosure.

FIG9 is a flow chart further illustrating the satellite-to-satellite handover process shown in FIG8.

10 is a call flow diagram illustrating a second example of a satellite-to-satellite handover procedure according to aspects of the present disclosure.

FIG. 11 is a flow chart further illustrating the satellite-to-satellite handover process shown in FIG. 10 .

12 is a call flow diagram illustrating a third example of a satellite-to-satellite handover procedure according to aspects of the present disclosure.

FIG13 is a flow chart further illustrating the satellite-to-satellite handover process shown in FIG12.

14 is a call flow diagram illustrating a fourth example of a satellite-to-satellite handover procedure according to aspects of the present disclosure.

FIG15 is a flow chart further illustrating the satellite-to-satellite handover process shown in FIG14.

16 is a block diagram illustrating an example of an apparatus employing processing circuitry that may be configured according to certain aspects disclosed herein.

Like reference numerals designate corresponding parts throughout the drawings.

DETAILED DESCRIPTION

Aspects of the present disclosure are described below in the description and related drawings for specific examples. Without departing from the scope of the present disclosure, alternative examples can be designed. In addition, well-known elements will not be described in detail or will be omitted so as not to obscure the relevant details of the present disclosure.

Aspects of the present disclosure provide handover procedures for satellite communication systems, such as broadband low-Earth orbit (LEO) satellite communication systems. As described in further detail below, some aspects provide methods for a gateway and a user terminal to coordinate and schedule satellite-to-satellite handovers such that there is no round-trip message delay between the last return service link (RSL) packet sent from the user terminal to the source satellite and the first RSL packet sent from the user terminal to the target satellite. In this way, any interruption on the return link (from the user terminal to the gateway) and any interruption on the forward link (from the gateway to the user terminal) can be reduced or limited.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects. Similarly, the term "aspects" does not require that all aspects include the discussed feature, advantage, or mode of operation.

The terms used herein are for the purpose of describing specific aspects only and are not intended to limit aspects. As used herein, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are also intended to include the plural forms. It will be further understood that, when used herein, the terms "comprises", "comprising", "includes" or "including" specify the presence of the stated features, wholes, steps, operations, elements or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components or combinations thereof. In addition, it is to be understood that the word "or" has the same meaning as the Boolean operator "OR", that is, it covers the possibilities of "either" and "both", and is not limited to "exclusive or" ("XOR"), unless otherwise expressly stated. It should also be understood that, unless otherwise expressly stated, the symbol "/" between two adjacent words has the same meaning as "or". In addition, phrases such as "connected to", "coupled to" or "in communication with..." are not limited to direct connection, unless otherwise expressly stated.

In addition, many aspects are described in terms of sequences of actions performed by elements of, for example, computing devices. It will be appreciated that the various actions described herein may be performed by specific circuitry, such as a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or various other types of general or special purpose processors or circuits, by program instructions executed by one or more processors, or by a combination of the two. In addition, these sequences of actions described herein may be considered to be fully embodied within any form of computer-readable storage medium having a corresponding set of computer instructions stored therein that, when executed, causes the associated processor to perform the functions described herein. Thus, various aspects of the present disclosure may be embodied in several different forms, all of which are contemplated to be within the scope of the claimed subject matter. In addition, for each of the aspects described herein, the corresponding form of any such aspect may be described herein as, for example, "logic configured to perform the described actions."

In the following description, many specific details, such as examples of specific components, circuits and processes, are set forth to provide a thorough understanding of the present disclosure. The term "coupled" as used herein means directly connected to or connected through one or more intermediate components or circuits. Moreover, in the description below, and for the purpose of explanation, specific terms are set forth to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that these specific details may not be required to practice the various aspects of the present disclosure. In other cases, well-known circuits and devices are shown in block diagram form to avoid obscuring the present disclosure. The various aspects of the present disclosure are not to be construed as being limited to the specific examples described herein, but include within their scope all implementations defined by the appended claims.

FIG1 shows an example of a satellite communication system 100, which includes a plurality of satellites in non-geosynchronous orbits (e.g., low earth orbit (LEO)) (although only one satellite 300 is shown for clarity of illustration), a gateway 200 in communication with the satellites 300, a plurality of user terminals (UTs) 400 and 401 in communication with the satellites 300, and a plurality of user equipment (UEs) 500 and 501 in communication with the UTs 400 and 401, respectively. Each UE 500 or 501 may be a user equipment, such as a mobile device, phone, smartphone, tablet, laptop, computer, wearable device, smartwatch, audio-visual device, or any device including the ability to communicate with a UT. In addition, the UE 500 and/or UE 501 may be a device (e.g., an access point, a small cell, etc.) for communicating with one or more end-user devices. In the example shown in FIG1 , UT 400 and UE 500 communicate with each other via a bidirectional access link (having a forward access link and a return access link), and similarly, UT 401 and UE 501 communicate with each other via another bidirectional access link. In another implementation, one or more additional UEs (not shown) may be configured to receive only and therefore communicate with the UT using only the forward access link. In another implementation, one or more additional UEs (not shown) may also communicate with UT 400 or UT 401. Alternatively, the UT and the corresponding UE may be integrated parts of a single physical device, such as, for example, a mobile phone with an integrated satellite transceiver and an antenna for communicating directly with a satellite.

The gateway 200 can access the Internet 108 or one or more other types of public, semi-dedicated or private networks. In the example shown in Figure 1, the gateway 200 communicates with the infrastructure 106, and the infrastructure 106 can access the Internet 108 or one or more other types of public, semi-dedicated or private networks. The gateway 200 can also be coupled to various types of communication backhauls, including, for example, landline networks such as fiber optic networks or public switched telephone networks (PSTN) 110. In addition, in alternative implementations, the gateway 200 can be connected to the Internet 108, PSTN 110 or one or more other types of public, semi-dedicated or private networks without using the infrastructure 106. In addition, the gateway 200 can communicate with other gateways such as gateway 201 through the infrastructure 106, or alternatively can be configured to communicate with the gateway 201 without using the infrastructure 106. The infrastructure 106 may include, in whole or in part, a network control center (NCC), a satellite control center (SCC), a wired and/or wireless core network, and/or any other components or systems for facilitating operation of and/or communications with the satellite communication system 100 .

The communication between satellite 300 and gateway 200 in two directions is called feeder link, and the communication between satellite and each UT in UT400 and 401 in two directions is called service link. The signal path from satellite 300 to ground station (which can be gateway 200 or one of UT 400 and 401) can be collectively referred to as downlink. The signal path from ground station to satellite 300 can be collectively referred to as uplink. In addition, as shown in the figure, the signal can have the overall directivity such as forward link (FL) and return link (RL) or reverse link. Accordingly, the communication link in the direction originating from gateway 200 and terminating at UT 400 by satellite 300 is called forward link, and the communication link in the direction originating from UT 400 and terminating at gateway 200 by satellite 300 is called return link or reverse link. Likewise, in FIG1 , the signal path from the gateway 200 to the satellite 300 is labeled a “forward feeder link” (FFL), while the signal path from the satellite 300 to the gateway 200 is labeled a “return feeder link” (RFL). In a similar manner, in FIG1 , the signal path from each UT 400 or 401 to the satellite 300 is labeled a “return service link” (RSL), while the signal path from the satellite 300 to each UT 400 or 401 is labeled a “forward service link” (FSL).

In a handover operation, the UT 400 may initially communicate with the gateway 200 via one of the first satellites 300 (e.g., the first satellite). When the first satellite orbits the earth, the gateway 200 and/or the UT 400 may not be able to communicate with each other via the first satellite. In some aspects of the present disclosure, the UT 400 may be a mobile unit that can be moved away from the communication range of the first satellite. In various aspects of the present disclosure, the gateway 200 includes a handover control block 299 that can cause the gateway 200 to perform a handover process that enables the UT to switch or transition to a different satellite 300 (e.g., a second satellite) with reduced message transmission-related delays. After the handover, the UT 400 can continue to communicate with the same gateway 200 or a different gateway 201. The UT 400 may also include a handover control block 499 that is configured to perform handover functions that will be described in further detail below, for example, with respect to Figures 7-16.

FIG2 is an example block diagram of a gateway 200, which may also be applied to the gateway 201 of FIG1. Gateway 200 is shown to include several antennas 205, an RF subsystem 210, a digital subsystem 220, a public switched telephone network (PSTN) interface 230, a local area network (LAN) interface 240, a gateway interface 245, and a gateway controller 250. RF subsystem 210 is coupled to antennas 205 and digital subsystem 220. Digital subsystem 220 is coupled to PSTN interface 230, LAN interface 240, and gateway interface 245. Gateway controller 250 is coupled to RF subsystem 210, digital subsystem 220, PSTN interface 230, LAN interface 240, and gateway interface 245. In various examples, gateway controller 250 may be implemented by processing circuit 1602 shown in FIG16.

The gateway controller 250 is coupled to a memory 252. The memory 252 may include instructions for execution by the gateway controller 250 and data for processing by the gateway controller 250. The memory 252 may include a non-transitory computer-readable medium (e.g., one or more non-volatile memory elements such as EPROM, EEPROM, flash memory, hard drive) storing instructions that, when executed by a processor, cause the gateway 200 to perform operations including, but not limited to, those described herein. For example, the instructions may include code for performing satellite-to-satellite handover methods and processes with reduced message transmission delay between the gateway and the UT, as described below and shown in Figures 8-15.

The RF subsystem 210, which may include several RF transceivers 212, an RF controller 214, and an antenna controller 216, can transmit communication signals to the satellite 300 via a forward feeder link 301F and can receive communication signals from the satellite 300 via a return feeder link 301R. Although not shown for simplicity, each of the RF transceivers 212 may include a transmit chain and a receive chain. Each receive chain may include a low-noise amplifier (LNA) and a downconverter (e.g., a mixer) for amplifying and downconverting received communication signals, respectively, in a known manner. In addition, each receive chain may include an analog-to-digital converter (ADC) to convert received communication signals from analog signals to digital signals (e.g., for processing by the digital subsystem 220). Each transmit chain may include an upconverter (e.g., a mixer) and a power amplifier (PA) for upconverting and amplifying communication signals, respectively, to be transmitted to the satellite 300, in a known manner. Additionally, each transmit chain may include a digital-to-analog converter (DAC) to convert digital signals received from the digital subsystem 220 into analog signals to be transmitted to the satellite 300 .

The RF controller 214 can be used to control various aspects of the RF transceivers 212 (e.g., selection of carrier frequency, frequency and phase calibration, gain settings, etc.). The antenna controller 216 can control various aspects of the antenna 205 (e.g., beamforming, beam steering, gain settings, frequency tuning, positioning, alignment, etc.).

The digital subsystem 220 may include a number of digital receiver modules 222, a number of digital transmitter modules 224, a baseband (BB) processor 226, and a control (CTRL) processor 228. The digital subsystem 220 may process communication signals received from the RF subsystem 210 and forward the processed communication signals to the PSTN interface 230 and/or the LAN interface 240, and may process communication signals received from the PSTN interface 230 and/or the LAN interface 240 and forward the processed communication signals to the RF subsystem 210.

Each digital receiver module 222 may correspond to a signal processing element for managing communications between the gateway 200 and the UT 400. One of the receive chains of the RF transceiver 212 may provide an input signal to multiple digital receiver modules 222. Several digital receiver modules 222 may be used to accommodate all satellite beams and possible diversity mode signals being processed at any given time. Although not shown for simplicity, each digital receiver module 222 may include one or more digital data receivers, a searcher receiver, and a diversity combiner and decoder circuit. The searcher receiver may be used to search for an appropriate diversity mode for a carrier signal and may be used to search for a pilot signal (or other relatively fixed pattern strong signal).

The digital transmitter modules 224 can process signals for transmission to the UT 400 via the satellite 300. Although not shown for simplicity, each digital transmitter module 224 can include a transmit modulator that modulates data for transmission. The transmit power of each transmit modulator can be controlled by a corresponding digital transmit power controller (not shown for simplicity), which can (1) apply a minimum level of power for interference reduction and resource allocation purposes, and (2) apply an appropriate level of power when necessary to compensate for attenuation and other path transfer characteristics in the transmission path.

A control processor 228 coupled to the digital receiver module 222, the digital transmitter module 224, and the baseband processor 226 may provide command and control signals to enable functions such as, but not limited to, signal processing, timing signal generation, power control, switching control, diversity combining, and system connectivity.

The control processor 228 may also control the generation and power of pilot, synchronization, and paging channel signals and their coupling to a transmit power controller (not shown for simplicity). The pilot channel is a signal that is not modulated by data and may use a repeating, constant pattern or constant frame structure type (pattern) or tone type input. For example, the orthogonal function used to form the channel for the pilot signal typically has a constant value such as all 1s or 0s, or a well-known repeating pattern such as a structured pattern of interspersed 1s and 0s.

The baseband processor 226 is well known in the art and is therefore not described in detail herein. For example, the baseband processor 226 may include various known elements such as, but not limited to, an encoder, a data modem, and digital data switching and storage components.

The PSTN interface 230 can provide communication signals to and receive communication signals from an external PSTN directly or through additional infrastructure 106, as shown in FIG1 . The PSTN interface 230 is well known in the art and is therefore not described in detail herein. For other implementations, the PSTN interface 230 can be omitted or replaced with any other suitable interface that connects the gateway 200 to a ground-based network (e.g., the Internet).

LAN interface 240 can provide communication signals to and receive communication signals from an external LAN. For example, LAN interface 240 can be coupled to Internet 108 directly or through additional infrastructure 106, as shown in FIG1 . LAN interface 240 is well known in the art and, therefore, will not be described in detail herein.

The gateway interface 245 can provide communication signals to and receive communication signals from one or more other gateways associated with the satellite communication system 100 of FIG. 1 (and/or to/from gateways associated with other satellite communication systems, not shown for simplicity). For some implementations, the gateway interface 245 can communicate with the other gateways via one or more dedicated communication lines or channels (not shown for simplicity). For other implementations, the gateway interface 245 can communicate with the other gateways using the PSTN 110 and/or other networks, such as the Internet 108 (see also FIG. 1 ). For at least one implementation, the gateway interface 245 can communicate with the other gateways via the infrastructure 106.

The gateway controller 250 can provide overall gateway control. The gateway controller 250 can plan and control the utilization of satellite 300 resources by the gateway 200. For example, the gateway controller 250 can analyze trends, generate service plans, allocate satellite resources, monitor (or track) satellite positions, and monitor the performance of the gateway 200 and/or satellite 300. The gateway controller 250 can also be coupled to a ground-based satellite controller (not shown for simplicity) that maintains and monitors the orbit of the satellite 300, relays satellite usage information to the gateway 200, tracks the position of the satellite 300, and/or adjusts various channel settings of the satellite 300. The gateway controller 250 can also include a handover control block 254, which can be configured by handover software in the memory 252. According to the methods described below and illustrated in Figures 8-15, the handover control block 254 can plan, control, and facilitate the handover of a UT from one satellite to another while minimizing the disruption of communications between the UT and the gateway. For example, the handover control block 254 can be configured to generate and send one or more control messages to the UT by enabling the UT to align with a new satellite (target satellite), the control messages being configured to facilitate a satellite-to-satellite handover, such as a start time or time window when the UT is to perform the handover, and information about time and frequency resources (communication resources) for the UT to use to transmit to the target satellite. These control messages can include handover messages, broadcast control information, and/or ephemeris broadcasts. The handover control block 254 can also be configured to receive and process a handover confirmation message, which can be received from the UT in response to the handover message.

2 , gateway controller 250 includes a local time, frequency, and position reference 251 that can provide local time and frequency information to RF subsystem 210, digital subsystem 220, and/or interfaces 230, 240, and 245. The time and frequency information can be used to synchronize the various components of gateway 200 with each other and/or with satellite 300. Local time, frequency, and position reference 251 can also provide position information (e.g., ephemeris data) of satellite 300 to the various components of gateway 200. Furthermore, for other implementations, while not depicted in FIG2 as being included within gateway controller 250, local time, frequency, and position reference 251 can be a separate subsystem coupled to gateway controller 250 (and/or to one or more of digital subsystem 220 and RF subsystem 210).

2 for simplicity, the gateway controller 250 may also be coupled to a network control center (NCC) and/or a satellite control center (SCC). For example, the gateway controller 250 may allow the SCC to communicate directly with the satellites 300, e.g., to retrieve ephemeris data from the satellites 300. The gateway controller 250 may also receive processed information (e.g., from the SCC and/or NCC) that allows the gateway controller 250 to properly aim its antenna 205 (e.g., at the appropriate satellite 300), schedule beam transmissions, coordinate handoffs, and perform various other well-known functions.

3 is an example block diagram of a satellite 300 for illustrative purposes only. It will be appreciated that a particular satellite configuration may vary significantly and may or may not include onboard processing. In addition, although illustrated as a single satellite, two or more satellites using inter-satellite communications may provide a functional connection between the gateway 200 and the UT 400. It will be appreciated that the present disclosure is not limited to any particular satellite configuration, and any satellite or combination of satellites that may provide a functional connection between the gateway 200 and the UT 400 may be considered within the scope of the present disclosure. In one example, the satellite 300 is shown to include a forward transponder 310, a return transponder 320, an oscillator 330, a controller 340, forward link antennas 351-352, and return link antennas 361-362. The forward transponder 310, which can process communication signals within a corresponding channel or frequency band, may include a respective one of first bandpass filters 311(1)-311(N), a respective one of first LNAs 312(1)-312(N), a respective one of frequency converters 313(1)-313(N), a respective one of second LNAs 314(1)-314(N), a respective one of second bandpass filters 315(1)-315, and a respective one of PAs 316(1)-316(N). As shown in FIG3 , each of the PAs 316(1)-316(N) is coupled to a respective one of the antennas 352(1)-352(N).

Within each of the respective forward paths FP(1)-FP(N), a first bandpass filter 311 passes signal components having frequencies within the channel or frequency band of the respective forward path FP and filters signal components having frequencies outside the channel or frequency band of the respective forward path FP. Thus, the passband of the first bandpass filter 311 corresponds to the width of the channel associated with the respective forward path FP. A first LNA 312 amplifies the received communication signal to a level suitable for processing by a frequency converter 313. Frequency converter 313 converts the frequency of the communication signal in the respective forward path FP (e.g., to a frequency suitable for transmission from satellite 300 to UT 400). A second LNA 314 amplifies the frequency-converted communication signal, and a second bandpass filter 315 filters signal components having frequencies outside the associated channel width. A PA 316 amplifies the filtered signal to a power level suitable for transmission to UT 400 via the respective antenna 352. The return transponder 320, which includes N return paths RP(1)-RP(N), receives communication signals from the UT 400 along the return service link 302R via antennas 361(1)-361(N), and transmits communication signals to the gateway 200 along the return feeder link 301R via one or more antennas 362. Each of the return paths RP(1)-RP(N), which can process communication signals within a corresponding channel or frequency band, can be coupled to a respective one of the antennas 361(1)-361(N) and can include a respective one of the first bandpass filters 321(1)-321(N), a respective one of the first LNAs 322(1)-322(N), a respective one of the frequency converters 323(1)-323(N), a respective one of the second LNAs 324(1)-324(N), and a respective one of the second bandpass filters 325(1)-325(N).

Within each of the respective return paths RP(1)-RP(N), a first bandpass filter 321 passes signal components having frequencies within the channel or frequency band of the respective return path RP and filters signal components having frequencies outside the channel or frequency band of the respective return path RP. Thus, the passband of the first bandpass filter 321 may correspond to the width of the channel associated with the respective return path RP for some implementations. The first LNA 322 amplifies all received communication signals to a level suitable for processing by the frequency converter 323. The frequency converter 323 converts the frequency of the communication signals in the respective return path RP (e.g., to a frequency suitable for transmission from the satellite 300 to the gateway 200). The second LNA 324 amplifies the frequency-converted communication signals, and the second bandpass filter 325 filters signal components having frequencies outside the associated channel width. The signals from the return paths RP(1)-RP(N) are combined and provided to one or more antennas 362 via the PA 326. The PA 326 amplifies the combined signal for transmission to the gateway 200.

Oscillator 330, which may be any suitable circuit or device that generates an oscillating signal, provides a forward local oscillator signal LO(F) to frequency converters 313(1)-313(N) of forward transponder 310 and provides a return local oscillator signal LO(R) to frequency converters 323(1)-323(N) of return transponder 320. For example, frequency converters 313(1)-313(N) may use the LO(F) signal to convert communication signals from a frequency band associated with transmission of signals from gateway 200 to satellite 300 to a frequency band associated with transmission of signals from satellite 300 to UT 400. Frequency converters 323(1)-323(N) may use the LO(R) signal to convert communication signals from a frequency band associated with transmission of signals from UT 400 to satellite 300 to a frequency band associated with transmission of signals from satellite 300 to gateway 200.

Controller 340, coupled to forward transponder 310, return transponder 320, and oscillator 330, can control various operations of satellite 300, including, but not limited to, channel allocation. In one aspect, controller 340 can include a memory coupled to a processor (not shown for simplicity). In various examples, the processor can be implemented by processing circuit 1602 shown in FIG. 16 . The memory can include a non-transitory computer-readable medium (e.g., one or more non-volatile memory elements such as EPROM, EEPROM, flash memory, hard drive, etc.) storing instructions that, when executed by the processor, cause satellite 300 to perform operations including, but not limited to, those described herein.

An example of certain portions of UT 400 or 401 is shown in FIG4 . UT 400 can be configured to perform the switching method shown in FIG8-15 as described below. In FIG4 , at least one antenna 410 is provided for receiving forward link communication signals (e.g., from satellite 300), which are transmitted to an analog receiver 414 where they are down-converted, amplified, and digitized. Additional details of an example of antenna 410 are provided below and shown in FIG6 . A duplexer element 412 is typically used to allow the same antenna to serve both transmit and receive functions. Alternatively, a UT transceiver can employ separate antennas for operating at different transmit and receive frequencies.

The digital communication signal output by the analog receiver 414 is communicated to at least one digital data receiver 416A and at least one searcher receiver 418. Additional digital data receivers through 416N may be used to obtain a desired level of signal diversity, depending on the acceptable level of transceiver complexity, as will be apparent to those skilled in the relevant art.

At least one user terminal control processor 420 is coupled to digital data receivers 416A-416N and searcher receiver 418. Among other functions, control processor 420 provides basic signal processing, timing, power, and switching control or coordination, as well as selection of frequencies for signal carriers. Another basic control function that can be performed by control processor 420 is the selection or manipulation of functions used to process various signal waveforms. Signal processing performed by control processor 420 can include determining relative signal strength and calculating various relevant signal parameters. Such calculations of signal parameters such as timing and frequency can include the use of additional or separate dedicated circuitry to provide increased measurement efficiency or speed or improved allocation of control processing resources. In various examples, control processor 420 can be implemented by processing circuitry 1602 shown in FIG. 16 .

In a specific example, the control processor 420 may further include a handover manager 421 for managing the handover of the UT 400 from the first satellite to the second satellite. For example, the handover manager 421 may include a communication module, a handover message receiving module, a handover confirmation message sending module, a handover scheduling module, a handover execution module, an FSL packet receiving module, an RSL packet receiving module, and an antenna alignment control module.

The handover manager 421 can be configured to perform satellite-to-satellite handovers via its respective modules, as described herein and illustrated, for example, in Figures 7-15. For example, the communication module can be configured to communicate with the gateway on a forward and/or reverse link, for example, via antenna 410. The handover message receiving module can be configured to receive and process handover messages (e.g., including handover parameters corresponding to satellite-to-satellite handovers) sent from the gateway via a satellite. The handover confirmation message sending module can be configured to generate a handover confirmation message in response to the received handover message and send it to the gateway via a satellite. The handover scheduling module can be configured to schedule a handover from a first satellite to a second satellite based on the received handover message. The handover execution module can be configured to execute a handover from a first satellite to a second satellite. The FSL packet receiving module can be configured to receive and process FSL packets, including but not limited to the first FSL packet after the handover. The RSL packet sending module can be configured to generate and send RSL packets, including but not limited to the first RSL packet before the handover. The antenna alignment and control module can be configured to control the alignment of antenna 410 and/or one or more feeds within antenna 410. That is, antenna 410 can follow or track one or more LEO satellites as they orbit and pass through the sky, and further, can realign from one satellite to another during a handoff process. Furthermore, the antenna alignment control circuitry can perform calculations or otherwise determine the direction to align antenna 410 based on information received from another node in the network (e.g., parameters in a handoff message received from gateway 200, information received from a broadcast channel, and/or an ephemeris broadcast).

The outputs of digital data receivers 416A-416N are coupled to digital baseband circuitry 422 within the user terminal. For example, digital baseband circuitry 422 includes processing and presentation elements for transmitting information to and from UE 500, as shown in FIG1 . Referring to FIG4 , if diversity signal processing is employed, digital baseband circuitry 422 may include a diversity combiner and decoder. Some of these elements may also operate under the control of, or in communication with, control processor 420.

When voice or other data is prepared as an outgoing message or communication signal originating from a user terminal, digital baseband circuitry 422 is used to receive, store, process, and otherwise prepare the desired data for transmission. Digital baseband circuitry 422 provides this data to a transmit modulator 426 that operates under the control of control processor 420. The output of transmit modulator 426 is passed to power controller 428, which provides output power control to transmit power amplifier 430 for ultimate transmission of the outgoing signal from antenna 410 to a satellite (e.g., satellite 300).

In FIG4 , the UT transceiver also includes a memory 432 associated with the control processor 420. The memory 432 may include instructions for execution by the control processor 420 and data for processing by the control processor 420. The memory 432 may include a non-transitory computer-readable medium (e.g., one or more non-volatile memory elements, such as EPROM, EEPROM, flash memory, hard drive, etc.) storing instructions that, when executed by the processor, cause the UT 400 to perform operations including, but not limited to, those described herein. In one aspect of the present disclosure, the instructions may include handover code stored in the memory 432 for executing satellite-to-satellite handover methods and processes with reduced interruption during handover, as described below and illustrated in FIG8-15 . In one example, the UT 400 may include a handover control block 436 that may be configured by the handover code to perform functions related to satellite-to-satellite handover. For example, the handover control block 436 may be configured to operate in conjunction with the control processor 420 to compose, receive, transmit, and process handover control messages to or from a gateway via a satellite. Examples of handover control messages include received handover messages and sent handover confirmation messages. In addition, the handover control block 436 may receive one or more handover parameters in the handover message, including appropriate information for enabling the UT 400 to align its antenna 410 with the target satellite; information on the start time or time window for the UT 400 to perform the handover and/or the time and frequency resources for communicating with the target satellite.

4 , UT 400 also includes an optional local time, frequency, and/or position reference 434 that can provide local time, frequency, and/or position information to control processor 420 for various applications, including, for example, time and frequency synchronization of UT 400. For example, local time, frequency, and/or position reference 434 can include a Global Navigation Satellite System (GNSS) receiver, one type of which is the Global Positioning System (GPS).

Digital data receivers 416A-N and searcher receiver 418 are configured with signal correlation elements to demodulate and track specific signals. Searcher receiver 418 is used to search for pilot signals or other relatively strong signals with fixed patterns, while digital data receivers 416A-N are used to demodulate other signals associated with the detected pilot signals. However, digital data receiver 416 can be configured to track the pilot signal after acquisition to accurately determine the ratio of signal chip energy to signal noise and determine the pilot signal strength. Therefore, the outputs of these units can be monitored to determine the energy or frequency of the pilot signal or other signals. These receivers also employ frequency tracking elements that can be monitored to provide the control processor 420 with current frequency and timing information for the signal being demodulated.

Optionally, control processor 420 can use such information to determine the extent to which the received signal deviates from the oscillator frequency when scaled to the same frequency band. This and other information related to frequency error and frequency shift can be stored in storage or memory element 432 as desired.

The control processor 420 may also be coupled to a UE interface circuit 450 to allow communication between the UT 400 and one or more UEs. The UE interface circuit 450 may be configured as desired to communicate with various UE configurations and, accordingly, may include various transceivers and related components, depending on the various communication technologies used to communicate with the various UEs supported. For example, the UE interface circuit 450 may include one or more antennas or wired connections, a wide area network (WAN) transceiver, a wireless local area network (WLAN) transceiver, a local area network (LAN) interface, a public switched telephone network (PSTN) interface, and/or other known communication technologies configured to communicate with one or more UEs in communication with the UT 400.

FIG5 is a block diagram illustrating an example of a UE 500, which may also be applied to the UE 501 of FIG1. For example, the UE 500 shown in FIG5 may be a mobile device, a handheld computer, a tablet computer, a wearable device, a smart watch, or any type of device capable of interacting with a user. In addition, the UE may be a network-side device that provides connectivity to various end-user devices and/or various public or private networks. In the example shown in FIG5, the UE 500 may include a LAN interface 502, one or more antennas 504, a wide area network (WAN) transceiver 506, a wireless local area network (WLAN) transceiver 508, and a satellite positioning system (SPS) receiver 510. The SPS receiver 510 may be compatible with one or more global navigation satellite systems (GNSS), such as a global positioning system (GPS), a global navigation satellite system (GLONASS), a Galileo positioning system, and/or any other global or regional satellite-based positioning system. In alternative aspects, for example, the UE 500 may include a WLAN transceiver 508 (e.g., a Wi-Fi transceiver) with or without the LAN interface 502, the WAN transceiver 506, and/or the SPS receiver 510. Furthermore, the UE 500 may include additional transceivers, such as Bluetooth, ZigBee, and other known technologies, with or without the LAN interface 502, the WAN transceiver 506, the WLAN transceiver 508, and/or the SPS receiver 510. Accordingly, the elements shown for the UE 500 are provided only as an example configuration and are not intended to limit the configuration of a UE according to aspects disclosed herein.

5 , processor 512 is connected to LAN interface 502, WAN transceiver 506, WLAN transceiver 508, and SPS receiver 510. Optionally, motion sensor 514 and other sensors may also be coupled to processor 512. In various examples, processor 512 may be implemented by processing circuitry 1602 shown in FIG.

Memory 516 is connected to processor 512. In one aspect, memory 516 may include data 518 that may be sent to and/or received from UT 400, as shown in FIG1 . Referring to FIG5 , for example, memory 516 may also include stored instructions 520 that are executed by processor 512 to perform processing steps for communicating with UT 400. In addition, UE 500 may also include a user interface 522 that may include, for example, hardware and software for connecting the input or output of processor 512 to a user via light, sound, or tactile input or output. In the example shown in FIG5 , UE 500 includes a microphone/speaker 524, a key 526, and a display 528 connected to user interface 522. Alternatively, the user's tactile input or output may be integrated with display 528 using, for example, a touch screen display. Again, the elements shown in FIG. 5 are not intended to limit the configuration of the UE disclosed herein, and it will be understood that the elements included in UE 500 will vary based on the end use of the device and the design choices of system engineers.

Additionally, UE 500 may be user equipment, such as a mobile device or external network-side device that communicates with but is separate from UT 400 as shown in FIG 1. Alternatively, UE 500 and UT 400 may be integrated parts of a single physical device.

The above-mentioned non-geosynchronous (e.g., LEO) satellite communication systems are one option that may be used to provide access to high-speed Internet or other data services in rural or remote areas. That is, deployment of terrestrial cable or fiber optic networks may not be feasible, especially when far away from relatively densely populated cities or areas. Similarly, terrestrial wireless access networks (e.g., Long Term Evolution (LTE) or other cellular networks) require backhaul connections to the Internet backbone, which may not be available in these areas.

Internet or data services can be provided to these areas via geostationary satellite networks. In these networks, geostationary satellites orbit at relatively high altitudes (i.e., 35,800 km), and therefore, propagation delays can be quite significant. This can result in a reduction in service quality. Another potential disadvantage of these networks is that the number of satellites within the Earth's arc (geo-arc) is generally limited.

On the other hand, LEO satellite networks orbit at relatively low altitudes (e.g., 1,200 km), resulting in substantially reduced propagation delay and service degradation compared to geostationary satellite networks. Furthermore, the number of satellites in orbit can be much greater than the number of satellites in a geostationary satellite network. Accordingly, the capabilities of LEO satellite networks can be superior to those of geostationary satellite networks.

The handover process is a common concern across terrestrial wireless access networks, geostationary satellite networks, and LEO satellite networks. For example, in terrestrial cellular networks, one serving base station hands over a user device to another base station. Satellite networks, whether geostationary or LEO, also perform handovers from one satellite to another. However, due to the specific characteristics of each of these networks, the procedures and algorithms used to implement handovers differ.

For example, in terrestrial radio access networks, control messages typically take only a few microseconds to propagate from a base station to a user terminal. Given these short propagation times, the time required to handover a user equipment from one base station to another is typically dominated by processing time in the core network. Furthermore, typical handover protocols in these networks may require several round-trip delays during the outage between the source and target cells. Furthermore, typical handover protocols in these networks utilize separate access channels and procedures for user equipment to gain access to the target cell after a handover.

In these terrestrial wireless access networks, typical user devices utilize non-directional (e.g., omnidirectional) antennas that allow simultaneous communication with multiple base stations. Therefore, there is no need to consider aiming the antenna at one base station or another during a handoff. Furthermore, with these non-directional antennas, the time at which a handoff will occur can be determined in real time based on measurements of signal strength from nearby base stations. The time at which a handoff will occur cannot be predicted by the network and does not necessarily have any pattern or regularity, and is based solely on these signal measurements as the user device moves or channel conditions change in other ways.

A typical LEO satellite phone system includes a user terminal with an antenna that can receive signals from multiple satellites simultaneously. Therefore, except for the relatively long delay (e.g., tens of milliseconds) for control signaling, the handoff process for LEO satellite phones can be handled similarly to a handoff process in terrestrial cellular networks. That is, the signal strengths from multiple satellites can be periodically measured, and the handoff can be based on the relative signal strengths.

In geostationary satellite communication networks, the handover process has many similarities to that in terrestrial wireless access networks. One significant difference is that via geostationary satellites, the time it takes for a control message to propagate from the gateway to the user terminal can be on the order of hundreds of milliseconds.

However, broadband LEO satellite systems present their own specific considerations and challenges for the handover process. Referring to FIG1 , in this disclosure, the handover of interest is the handover of a user terminal (e.g., UT 400) from one satellite 300 to another. It will be understood that user equipment 500 may also undergo a handover from one user terminal to another.

In a LEO satellite communication system, the propagation time of control messages from the gateway 200 to the user terminal 400 via the LEO satellite is lower than that of a geostationary satellite telephone network, but greater than that of a terrestrial wireless access network. In a typical LEO network implementation, the user terminal 400 can send and receive signals from any satellite 45° or more above the horizon, while the gateway 200 can send and receive signals from any satellite 20° or more above the horizon. Given the LEO satellite altitude, these parameters indicate the maximum distance between the user terminal 400 and the gateway 200. At the maximum distance, with the user terminal 400 operating at an inclination angle of 45° and the gateway operating at an inclination angle of 20°, the total propagation delay between the gateway 200 and the user terminal 400, excluding any processing time of the satellite 300, is approximately 18ms, and the round-trip delay (again ignoring any processing delays at any node) is approximately 36ms. In this disclosure, a message transmission round-trip delay refers to the time for a message transmission to propagate from the user terminal to the gateway via the satellite, and for the message transmission to propagate from the gateway back to the user terminal via the satellite. Messaging round trip delay may also refer to the time for a message transmission to propagate from a gateway to a user terminal via a satellite, and from the user terminal back to the gateway via a satellite.

In LEO satellite networks, switching based on signal measurements may be impractical. That is, the user terminal 400 may include a relatively large and directional antenna that may be cumbersome to move quickly to aim at different satellites to determine whether switching is warranted. If an expensive option is employed, duplication of the antenna to allow simultaneous aiming at different satellites is possible. Similarly, a phased array antenna capable of accessing two satellites simultaneously is a relatively expensive option. Single-aperture antennas with multiple antenna feeds are known in the art, and while they can reduce cost relative to duplicating the antenna aperture, they are still relatively expensive relative to single-feed, single-aperture antennas.

In the case of the examples above: replicated aperture, phased array or multi-feed antennas, overlapping or substantially instantaneous switching processes can be implemented. Such overlapping or substantially instantaneous switching processes are outside the scope of the present disclosure. However, in networks with some user terminals capable of such overlapping or substantially instantaneous switching processes, as well as other networks utilizing the switching processes described in detail below, the gateway 200 can maintain a database of the type of switching utilized by each user terminal. In another example, the type of switching can be notified from the user terminal to the gateway 200 as part of a switching confirmation message, which will be described in further detail below. Throughout the present disclosure, antennas can be repositioned mechanically, electronically and/or a combination of both.

To achieve higher data rates, as briefly mentioned above, the user terminal 400 can include a directional antenna that can be aimed at a specific satellite in the sky. As an example, a simple Luneburg lens with a single movable feed and a simple azimuth/elevation mechanism can be used. FIG6 is an illustration of an example of a mechanically steered single feed antenna 600 that can be included in the user terminal 400 as shown or described in any of FIG1, 4, 7, 8, 10, 12, and/or 14. In a specific example, the antenna 600 can be used as the antenna 410 in the UT 400 shown in FIG4.

In some examples, antenna 600 may be a Luneburg antenna including lens 608. The mechanism for moving antenna feed 602 to align with a satellite may employ a low-cost stepper motor 604 for driving a flexible toothed belt 606 to drive antenna feed 602 along a curved track 605, and a stepper motor 609 for rotating antenna 600 in azimuth about a vertical axis.

The connection between the feed 602 and the external electronics can be a cable pack, i.e., a wire or cable (not shown) extending from the antenna feed housing 607 away from the antenna 600. Cable packs, while relatively inexpensive, can withstand a limited range of rotation for the antenna feed. In some cases, the antenna feed may be rotated to a new position in the direction of unwinding the cable, which may not be the shortest path to the new position. An alternative option to enable continuous rotation of the antenna 600 is to utilize a rotary joint. However, rotary joints are more expensive than cable packs and may have reliability issues.

Unlike terrestrial wireless access networks, in broadband LEO satellite communication networks, the time at which a handoff from one satellite to another will occur can be predicted. That is, because the satellites' orbits are known and predictable, the handoff from a descending satellite to an ascending satellite can be timed and scheduled, rather than relying on measurements of the instantaneous signal strength from the satellites. Accordingly, a single antenna aperture and receiver chain, as well as a single antenna feed, can be used to simultaneously focus on a single satellite. The antenna or antenna feed can be quickly moved or realigned from the source satellite to the target satellite during the handoff process without requiring any signal measurements or sending measurement reports to the gateway.

However, this handover process in LEO satellite communication systems presents specific challenges to address. Specifically, if more than necessary message exchanges occur, the longer propagation delay relative to the terrestrial wireless access network can cause the handover process to extend for an extended period of time. Consequently, the multiple round-trip delays for message exchanges in typical terrestrial wireless access networks can be unacceptable in LEO satellite communication systems. Furthermore, the use of separate access channels and procedures to gain access to the target satellite can result in unacceptably long handover interruptions. While the satellite orbits may be known and predictable, the geometry of the satellite orbits can vary relative to one another, making each handover potentially different from the next. If cable wrap is used, a cable unwinding cycle may be required in certain handovers, increasing the time required to realign the antenna from one satellite to the next. Due to these variables, the total time required for a handover can vary significantly, for example, from hundreds of milliseconds to over a second. However, in all handovers, it is desirable to reduce or minimize the duration of any disconnection of the data link during the satellite-to-satellite handover process.

One known algorithm for single-satellite beam-to-beam handoff reduces call drop rates in multi-beam communication systems (e.g., LEO satellite communication systems). In this known algorithm, a messaging protocol is implemented between a gateway and a user terminal. Based on messages sent from the user terminal to the gateway, the gateway can determine a more desirable beam for transmitting data or information to the user terminal. Furthermore, known algorithms for satellite-to-satellite handoff disclose satellite communication systems in which one or more user terminals within a satellite's coverage area can be switched to another communication service by sending a control signal to the user terminal. Here, the control signal can directly cause the identified user terminal to electronically realign one or more antennas associated with the user terminal to align the antenna with the position of a second satellite. However, none of these algorithms provide the satellite-to-satellite handoff characterized herein, in which the UT determines an internal schedule for the handoff based on handoff parameters received at an earlier time.

Accordingly, aspects of the present disclosure provide a handover process that can reduce or minimize the number of control message interactions while accommodating a wide range of antenna movement times.

As described in further detail below, the present disclosure provides processes and protocols for satellite-to-satellite handoffs, which may be referred to as handoffs from a source satellite to a target satellite. In some examples, both the source and target satellites communicate with the same gateway; in other examples, the source and target satellites communicate with different gateways.

7 is a diagram illustrating a handover scenario involving a UT 400, one or more gateways 200/201, and two satellites 300/301 according to aspects of the present disclosure. UT 400 may initially communicate with gateway 200 via a first satellite 300 (source satellite) in a LEO satellite communication system. As part of this communication, gateway 200 may schedule and allocate time and frequency resources for both the forward link and the return link.

The time for each of the nodes in the system can be an absolute time, such as a time derived from a GPS signal. In another example, the system time can be a time relative to a data frame boundary inherent in the data stream. The gateway 200 can configure appropriate timing or delays for transmissions to the respective satellites 300/301 so that the arrival of the signal at the UT 400 can be controlled. In one example, the timing of the signal can be aligned at the UT 400 or the satellite 300. When the time is aligned at the satellite 300, each transmitter can compensate the time so that the signal will arrive at the satellite 300 at the system reference time. In another example, a fixed time offset can be transmitted to the UE 400 or known by the UE 400.

When the first satellite 300 orbits and leaves the range of the UT 400 and/or the gateway 200, the gateway 200 and/or the UT 400 may cease to be able to communicate with each other via the first satellite 300. (In some cases, it is not the movement of the satellite 300 that causes the need for handover, but rather the UT 400 may move out of the communication range of the first satellite 300.) Therefore, during the handover process, the UT 400 may switch to communicating with the second satellite 301 (the target satellite) to maintain communication. After the handover, the UT 400 may maintain communication with the same gateway 200 or a different gateway 201. The UT, gateway, and satellite of FIG. 7 may be the same as any of the UTs, gateways, and satellites shown or described in FIG. 1-4, 8, 10, 12, and/or 14.

The following describes four exemplary processes for satellite-to-satellite handoffs according to various aspects of the present disclosure. In the first and second examples, after realigning with the target satellite, UT 400 can immediately begin transmitting a return link. In the first example, as shown in FIG8 , both the source and target satellites are in communication with the same gateway; and in the second example, as shown in FIG10-11 , the source satellite is in communication with a first gateway, and the target satellite is in communication with a second gateway. In the third and fourth examples, after realigning with the target satellite, UT 400 can wait until it receives a first forward link packet from the target satellite before beginning transmission of the return link. In the third example, as shown in FIG12-13 , both the source and target satellites are in communication with the same gateway; and in the fourth example, as shown in FIG14-15 , the source satellite is in communication with a first gateway, and the target satellite is in communication with a second gateway.

Referring now to FIG8 , a call flow diagram illustrates an exemplary satellite-to-satellite handover process 800 corresponding to the first example described above. As shown, the satellite-to-satellite handover process 800 may be performed by the gateway 200, the source satellite 300, the target satellite 301, and the user terminal 400 described above, and as illustrated, for example, in FIG1 , 2, 3, 4, 7, 10, 12, and/or 14.

8 , UT 400 may initially communicate with gateway 200 via a first satellite (source satellite) 300. For example, UT 400 may send RSL data 802 to the gateway via the first satellite 300 and/or receive FSL data corresponding to FFL data 804 from gateway 200 via the first satellite 300. As described with respect to FIG1 , gateway 200 may send data packets to UT 400 via the FFL (between gateway 200 and satellite 300) and the FSL (between satellite 300 and UT 400). Similarly, UT 400 may send data packets to gateway 200 via the RSL (between UT 400 and satellite 300) and the RFL (between satellite 300 and gateway 200). In the following discussion of the handover protocol 800, when an FSL data packet transmission occurs from a satellite 300, it is assumed that a corresponding FFL data packet is sent by the gateway 200 to the satellite 300, which forwards such data packet as an FSL data packet to the UT 400. Similarly, when an RSL data packet transmission occurs from a UT 400, it is assumed that such data packet is sent to the satellite 300, and a corresponding RFL data packet is sent by the satellite 300 to the gateway 200.

At an appropriate time, which may be a predetermined time or may be triggered by any event, at time 806, gateway 200 may calculate various handover parameters for a satellite-to-satellite handover of UT 400. Gateway 200 may then send these handover parameters in a handover message 808 to UT 400 via first satellite 300.

In one example, the handover parameters can be explicitly provided in the unicast handover message 808. In another example, the handover parameters can be propagated via a broadcast channel that informs all (or multiple) user terminals about satellite or realignment information.

The handover message 808 may include any suitable information or parameters for enabling the UT 400 to align with the target satellite 301. For example, the handover parameters may enable the UT 400 to determine when to perform a satellite-to-satellite handover and which satellite to handover to, or at least how to align with the next satellite.

For example, the handover message 808 may include ephemeris information, e.g., information providing the location of one or more satellites at a given time. In another example, the handover message 808 may include angle or geometry information configured to enable the UT 400 to realign its antenna/feed at an appropriate angle without having to have any visibility or knowledge of the actual location of the satellite. In yet another example, the handover message 808 may include a set of points or angles configured to enable the UT 400 to determine the azimuth and elevation of the satellite for realignment of the antenna/feed when handing over.

The handover message 808 may also include timing information for the handover. Here, the handover timing may correspond to absolute time or data frame relative time. As described above, absolute time may be derived from any suitable source, including but not limited to GPS transmission. In other examples, data frame relative timing may be used. Data is sent in time blocks called data frames. A data frame may include a single data packet or several data packets. A data packet may be user data or control data. Data frames may be numbered sequentially to facilitate tracking of lost data or as a simple way to track system time. In one example, a numbering system starts at midnight with frame zero and sequentially numbers frames throughout the day. Another example of a numbering system sequentially numbers data frames up to a maximum number (e.g., 255 using an eight-bit number) and then restarts from zero. In one example, data frame relative time is the time at which data frame N is sent or received relative to some other frame in the sequence. For example, data frame N-3 is sent three frame periods before data frame N.

The timing information for the switching time may, in some examples, be a start time for the switching, or a time window in which the switching will be performed by UT 400. When the switching timing information corresponds to a time window (e.g., an absolute time window or a data frame relative time window), if the transmission of a block or frame of scheduled data is in progress before the transmission is suspended for the switching, UT 400 may utilize the window as additional time to complete the transmission.

In some examples, the timing information may inform the UT 400 to look for a forward link packet with an indicator that the packet is the last forward link packet to be sent via the first satellite 300. Additional discussion of this indicator is provided below.

The handover message 808 may also include information on the time and frequency resources reserved for UT 400, to be used for transmission to the second satellite 301 after the handover, so that in the presence or absence of additional control messages after realigning the antenna, the flow of return link data can be quickly restored after the handover. Time and frequency resources are resources that can support data transmission to or from UT 400 via satellites (e.g., source satellite 300 and target satellite 301). Information about time and frequency resources can be explicitly transmitted to UT 400 in the handover message 808, or implicitly transmitted using an index to a table known to gateway 200 and UT 400, for example. In another example, a bitmap carried in the handover message 808 may be utilized to transmit information about time and frequency resources to UT 400.

Time and frequency resources can be continuous or discontinuous. If discontinuous, then resource can be shared with other UT (or other user) on the time and/or frequency that is not assigned to UT 400. For example, during UT 400 makes antenna realignment, time and frequency resource can be used for other user terminal in some examples, except the resource that can be used to send the first return link packet after switching. In some examples, the discontinuous pattern can be configured to accelerate or maximize the fast switching for more capable user terminal, and reduce the amount of time and frequency resource wasted by slower or less capable user terminal. In addition, any discontinuous pattern can be configured to make more resources available when UT 400 is most likely to send the first return link packet by target satellite 301 after switching. Further, the discontinuous pattern can be configured to provide more frequent return link transmission opportunities to adapt to user terminal with fast antenna (for example, faster realignment speed), or less frequent return link transmission opportunities to adapt to user terminal with slower antenna (for example, slower realignment speed), or user terminal with longer interruption time of antenna realignment in other aspects.

Accordingly, unlike signaling in terrestrial wireless access networks, the UT may not utilize a random access channel to gain access to a time and frequency communication resource allocation via a target satellite unless the handover fails and the UT enters recovery mode.

In another aspect of the present disclosure, the handover message 808 may include information regarding beam-to-beam switching. That is, a LEO satellite may transmit multiple beams to the ground. At any given time, UT 400 may be assigned to a specific one of these beams. As the satellite traverses the sky, the antenna at UT 400 may track the satellite and may switch from one beam to another over time. Thus, the handover parameters in the handover message 808 may include information regarding these beam-to-beam switching as well as the satellite-to-satellite handover information described above.

In various examples, handover message 808 can provide information regarding one or more handovers, or information that UT 400 can use to predict or schedule one or more handovers.

Based on the handover message 808, at 810, the UT 400 may set its internal schedule for the handover. That is, the handover message 808 may be configured to enable the UT 400 to predict the handover at a time before the handover occurs. The scheduled handover may occur at a later time, after the handover has been scheduled.

In some examples, the UT 400 can calculate the satellite position based on the ephemeris information in the handover message 808 or one or more broadcast messages to guide the antenna/feed to be aligned with the intercept target satellite 301 after the handover. In some examples, the UT 400 can calculate the direction to align the antenna/feed based on the information in the handover message 808 or one or more broadcast messages without requiring any direct knowledge of the actual position of the target satellite 301.

When UT 400 has set up its internal schedule for handoff, UT 400 may send a handoff acknowledgement message (ACK) 812. In this manner, UT 400 may inform gateway 200 that UT 400 has received handoff message 808 and may indicate that UT 400 will proceed with the handoff.

In some aspects, the ACK message may include an estimate of the time the UT needs to realign its antenna/feed with the target satellite 301. Here, the estimate may be based on the distance its azimuth and elevation positioner will move from being aligned with the source satellite to being aligned with the target satellite. The estimate may additionally or alternatively be based on the route used to achieve movement or realignment of the antenna/feed, including any cable deployment movement if required for a particular handoff. The gateway 200 may utilize the estimate to free up return link time and frequency resources reserved for the UT 400 during the handoff and allow other UTs or users to use these resources until the estimated move time expires.

As mentioned above, the execution of the handover itself can be scheduled for any suitable time, and in various examples can be a short time or a relatively long time after the transmission of the ACK message 812. That is, in addition to those data exchanges shown in Figure 8, in some aspects of the present disclosure, the gateway 200 and the UT 400 can have additional data exchanges between the handover message 808 and the last RSL/FSL packet transmission (discussed below). Therefore, after potential delays, the time for handover may occur. Of course, in some examples, the time for handover can occur immediately when the transmission of the ACK message 812. That is, in various aspects of the present disclosure, the ACK message 812 can serve as a trigger to start handover, or can provide information about a handover scheduled at a future time to the gateway 200.

When the time for handover arrives, gateway 200 may transmit a final forward link packet 814 to user terminal 400 via source satellite 300. In one aspect of the present disclosure, final forward link packet 814 is the last forward link packet received by UT 400 before realigning its antenna toward second satellite 301. As described above, UT 400 may be notified of the arrival of final forward link packet 814 in any of several ways: for example, via a schedule included in handover message 808; via signaling, such as broadcast signaling, which may be sent at or near the time of final forward link packet 814; and/or via an indicator embedded in final forward link packet 814. When final forward link packet 814 includes such a final packet indicator, the indicator may be provided in any suitable manner suitable for identifying the final forward link packet to be transmitted to UT 400 via source satellite 300. For example, the final packet indicator may be explicit in the protocol for packet framing of forward link packets. In another example, the indicator may be a reserved sequence number or frame number. Here, the sequence number or frame number that can be retained in the last forward link packet 814 can be used to indicate that the packet is the last packet. In another example, the last packet indicator can be provided by the inversion of the cyclic redundancy check (CRC) part of the last packet 814. In this example, the UT 400 can try non-inverted CRC and inverted CRC when decoding the packet so that it can determine that the inverted CRC has been used for specific packet. In some examples, the indication of the last forward link packet can be a single bit that can be transmitted by any protocol that can transmit a single bit.

In any examples utilizing a last packet indicator, such an indicator may be useful to upper layers at the UT 400. For example, an application running at the UT 400 may interpret the indicator as a signal to defer or suspend communications until the handoff is complete.

In some aspects of the present disclosure, the transmission of last forward link packet 814 can be optional.That is to say, forward link transmission may occur and does not happen to occur when switching. In some aspects of the present disclosure, any grouping in the forward link or return link packet after the switching message comprising last forward link packet 814 may fail or may be omitted, and UT 400 can still continue to reposition its antenna at the scheduled time. That is to say, in such an example, even under the situation that there is not this last forward link packet 814, switching also can come as scheduled and continue according to switching message 808. When sending last forward link packet, the grouping can be the grouping of any suitable format or class, comprises data packet or control packet.

After the transmission of the last forward link packet (if such transmission occurs), gateway 200 may terminate or suspend the forward link and, at 816, may begin buffering user data for forward link transmission until the handover is complete. For example, referring to FIG. 2 , gateway 200 may temporarily store user data for the forward link in a buffer (e.g., in memory 252).

When UT 400 receives last forward link packet 814, and/or when the time for scheduling switching occurs, UT 400 can start to make the switching begin.For example, UT 400 can send last return link packet 818 to gateway 200 via source satellite 300.Here, last return link packet 818 can comprise the grouping of user data, control signaling or any suitable type or category.In some examples, last return link packet 818 can comprise the confirmation (ACK) of last forward link packet 814.In other examples, can send ACK for last forward link packet 814 from UT 400 at a later time, for example, after the restart to the return link after switching is completed.In some examples, the transmission of last return link packet 818 can be optional.That is to say, may occur in the return link transmission that may not happen to occur at the switching time.In such an example, even when there is no such last return link packet 818, switching also can continue as scheduled according to handoff message 808.

In some aspects of the present disclosure, in addition to the data exchange shown in Figure 8, the gateway and the UT may also have additional data exchanges between the handover message and the final forward link/return link packet transmission. For example, these data exchanges may include ACK and NAK responses and appropriate corrective actions.

After the transmission of the last return link packet 818 (if such transmission occurs), the UT 400 may terminate or suspend the return link and, at 820, may begin buffering user data intended for return link transmission until the handover is complete. For example, referring to FIG. 4 , the UT 400 may temporarily store user data for the return link in a buffer, such as in the memory 432.

In addition, after the transmission of the last return link packet 818 (if such transmission occurs), at 822, UT400 can realign the antenna or feed source to align with the target satellite 301 according to the switch. Here, in one aspect of the present disclosure, when there is or does not exist an additional control message after the antenna is realigned, UT 400 can start the realignment of the antenna or feed source immediately (or as quickly as possible, or after an appropriate delay) after the completion of the transmission of the last return link packet 818. In the example where the last return link packet is not sent, UT 400 can start the realignment of the antenna or feed source immediately at the time of being scheduled for switching according to the switch message 808. As mentioned above, the realignment of the antenna or feed source may involve, depending on the nature of the antenna in the UT 400, moving the feed source 602 (see FIG. 6), moving the antenna, or realigning the beam (e.g., using a phased array antenna). In some examples, if a cable package is used in UT400, then as mentioned above, realigning the antenna can also include a cable expansion cycle.

In some aspects of the present disclosure, other scenarios of data exchange between UT 400 and gateway 200 may occur after the handover ACK message 812 and before UT 400 realigns its antenna. For example, these data exchanges may include ACK and NACK responses and appropriate corrective actions if the time between scheduling the handover and starting to move the antenna allows.

When the realignment of the antenna/feed is complete, UT 400 can begin transmission of the return link, including any buffered return link data, to gateway 200 via target satellite 301. Here, the time to begin return link transmission can correspond to the completion of the movement of the antenna or feed. In addition, the transmission can utilize at least a portion of the time and frequency resources reserved for transmission through target satellite 301 and indicated to UT 400 in handover message 808.

At this point, gateway 200 may monitor reserved time and frequency resources for return link transmission from UT 400 via target satellite 301 and may accordingly receive a first return link packet 824 from UT 400 via target satellite 301 at 826 .

In aspects of the present disclosure, the gateway 200 may recognize the receipt of the first return link packet 824 from the UT 400 via the target satellite 301 as confirmation of a successful handover, indicating that the handover is complete and that transmission on the forward link may continue. Accordingly, upon receiving the first return link packet 824 from the UT 400 via the target satellite 301, the gateway 200 may begin forward link transmission to the UT 400 via the target satellite 301, including any buffered forward link data.

FIG9 is a flow diagram illustrating an exemplary process 900 for satellite-to-satellite handover according to some aspects of the present disclosure, e.g., corresponding to the call flow diagram of FIG8. Handover process 900 may be performed by a UT shown in any of FIG1, 4, 7, 8, 10, 12, and/or 14. In one specific example, the UT may be UT 400 shown in FIG4, which is equipped with an antenna similar to antenna 600 shown in FIG6.

At block 902, UT 400 may communicate with a gateway (e.g., gateway 200) via a first satellite (e.g., satellite 300). For example, a forward link may flow from the gateway to the UT via the first satellite, and a return link may flow from the UT to the gateway via the first satellite.

At block 904, UT 400 may receive a handover message from the gateway via the first satellite. Here, the handover message may include information sufficient for UT 400 to identify the target satellite and determine a time for handover from the first satellite to the target satellite. In other words, the handover message may identify the second satellite as the target satellite for handover, or may include appropriate parameters for enabling UT 400 to realign its antenna toward the second satellite.

At block 906, UT 400 may schedule a handoff from the first satellite to the second satellite based on the handoff message. Here, the handoff may be scheduled at a later time, for example, corresponding to an orbital pattern of LEO satellites in a LEO satellite communication network. In some examples, scheduling the handoff may include determining a direction for aligning an antenna at UT 400 with the second satellite based on at least one of: information included in the handoff message, information received from a broadcast channel, or an ephemeris broadcast.

In response to the handover message, UT 400 may send a handover confirmation message to the gateway via the first satellite at block 908. In some examples, the handover confirmation message may include an estimated time for realigning the antenna to the second satellite.

As shown in Figure 9, a period of time may pass after the handover confirmation message is sent. That is, the handover confirmation message may be sent independently of the time at which the actual handover occurs. Here, the time for handover as indicated in the handover message may correspond to the satellite's orbital pattern.

At block 910, UT 400 may receive a last forward link packet from the gateway via the first satellite. In some examples, the last forward link packet may be identified as being the last forward link packet, for example, by at least one of: a schedule or frame number included in a handover message, a signaling message received from the gateway, and/or an indication embedded in the last forward link packet.

At block 912, UT 400 may transmit the last return link packet to the gateway via the first satellite. After transmitting the last return link packet, UT 400 may perform a handoff from the first satellite to the second satellite. That is, at block 914, UT 400 may terminate or suspend return link transmission via the first satellite and may begin buffering return link data while realigning the antenna. Accordingly, at block 916, UT 400 may realign the antenna from the first satellite to the second satellite and, at block 918, may initiate transmission on the return link via the second satellite.

As described above, in one aspect of the present disclosure, UT 400 may not receive handover control packets from the gateway during the time period between the last forward link packet transmission and the first forward link packet transmission. Here, handover control packets refer to packets related to handover, and it is understood that other signaling may occur, such as reference signals that may be used by the UT to perform channel estimation prior to its return link transmission.

FIG10 is a call flow diagram illustrating a second exemplary satellite-to-satellite handover process 1000 as described above. As shown, the satellite-to-satellite handover process 1000 may be performed by the first gateway 200, the second gateway 201, the source satellite 300, the target satellite 301, and the user terminal 400 described above, and illustrated, for example, in FIG1, 2, 3, 4, 7, 8, 12, and/or 14.

In this example, although much of the process is the same or similar to the process described above and shown in FIG8 , here the source satellite 300 communicates with the first gateway 200, and the target satellite 301 communicates with the second gateway 201. Because most of the steps and actions in process 1000 are the same or similar to those in process 800, those actions are not described here for the sake of brevity.

In this example, upon scheduled handoff, first gateway 200 may send a final forward link packet 1002 to UT 400 via source satellite 300. Following transmission of the final forward link packet (if such transmission occurs), at 1004, first gateway 200 may terminate or suspend the forward link.

In one aspect of the present disclosure, after the transmission of the last forward link packet 1002, at 1004, the first gateway 200 can terminate the flow corresponding to the forward link. That is, because in this example, UT 400 is being handed off to the target satellite 301 that is communicating with a different gateway, the first gateway 200 can end the communication session and begin other activities. In some examples, after the transmission of the last forward link packet 1002, the first gateway may still have (e.g., stored in a transmission buffer) one or more packets for UT 400 that were not sent in the forward link flow. In another example, after the transmission of the last forward link packet 1002, one or more packets for UT 400 can be sent to the first gateway 200.

In any of these cases, some examples may simply discard these packets after the transmission of the last forward link packet 1002. However, in other examples, a communication link may exist between the first gateway 200 and the second gateway 201. For example, as shown in FIG1 , both gateways 200 and 201 may be connected to the network infrastructure 106 and, accordingly, may be able to exchange packets with each other. Thus, after the transmission of the last forward link packet 1002, at 1006, the first gateway 200 may forward or transmit any packets destined for the UT 400 to the second gateway 201.

Furthermore, after the transmission of the last forward link packet 1002, appropriate signaling and communications may occur to indicate to the infrastructure 106 that the second gateway 201 will be the node from which forward link data will be sent to the UT 400. Thus, at this point, at 1008, the second gateway 201 may begin buffering any forward link data it may receive from the infrastructure 106 until the handoff is complete. The remainder of the handoff process 1000 is substantially the same as the first example described above and shown in FIG8 .

FIG11 is a flow diagram illustrating an exemplary process 1100 for satellite-to-satellite handoff according to aspects of the present disclosure, e.g., corresponding to the call flow diagram of FIG10. The handoff process 1100 may be performed by a UT shown in any of FIG1, 4, 7, 8, 10, 12, and/or 14. In one specific example, the UT may be UT 400 shown in FIG4, equipped with an antenna similar to antenna 600 shown in FIG6.

At block 1102, UT 400 may communicate with a first gateway (e.g., gateway 200) via a first satellite (e.g., satellite 300). For example, a forward link may flow from the first gateway to the UT via the first satellite, and a return link may flow from the UT to the first gateway via the first satellite.

At block 1104, UT 400 may receive a handover message from the first gateway via the first satellite. Here, the handover message may include information sufficient for UT 400 to identify the target satellite and determine a time for handover from the first satellite to the target satellite. In other words, the handover message may identify the second satellite as the target satellite for handover, or may include appropriate parameters for enabling UT 400 to realign its antenna toward the second satellite.

At block 1106, UT 400 may schedule a handoff from the first satellite to the second satellite based on the handoff message. Here, the handoff may be scheduled at a later time, for example, corresponding to an orbital pattern of LEO satellites in a LEO satellite communication network. In some examples, scheduling the handoff may include determining a direction for aligning an antenna at UT 400 toward the second satellite based on at least one of: information included in the handoff message, information received from a broadcast channel, or an ephemeris broadcast.

In response to the handover message, UT 400 may send a handover confirmation message to the first gateway via the first satellite at block 1108. In some examples, the handover confirmation message may include an estimated time for realigning the antenna to the second satellite.

As shown in Figure 11, a period of time may elapse after the transmission of the handover confirmation message. That is, the transmission of the handover confirmation message may be performed independently of the time at which the actual handover occurs. Here, the time for the handover may correspond to the orbital pattern of the satellite, as indicated in the handover message.

At block 1110, UT 400 may receive a last forward link packet from a first gateway via a first satellite. In some examples, the last forward link packet may be identified as being the last forward link packet, for example, by at least one of: a schedule or frame number included in a handover message, a signaling message received from the gateway, and/or an indication embedded in the last forward link packet.

At block 1112, UT 400 may transmit the last return link packet to the first gateway via the first satellite. After transmission of the last return link packet, UT 400 may perform a handoff from the first satellite to the second satellite. That is, at block 1114, UT 400 may terminate or suspend return link transmission via the first satellite and may begin buffering return link data while realigning the antenna. Accordingly, at block 1116, UT 400 may realign the antenna from the first satellite to the second satellite and, at block 1118, may initiate transmission on the return link to the second gateway via the second satellite.

As described above, in aspects of the present disclosure, UT 400 may not receive a handoff control packet from the gateway during a time period between a last forward link packet transmission and a first forward link packet transmission.

While the above discussion of Figures 8-11 relates to an exemplary algorithm in which, after realigning the antenna, UT 400 immediately begins transmission on the return link via the target satellite, this is not the only example within the scope of the present disclosure. That is, in another aspect of the present disclosure, as described below and illustrated in Figures 12-15, after realigning the antenna, UT 400 may continue to buffer return link data until it receives the first forward link packet, after which UT 400 may begin transmission on the return link.

For example, Figure 12 is a call flow diagram illustrating a third exemplary satellite-to-satellite handover process 1200. As shown, the satellite-to-satellite handover process 1200 may be performed by the gateway 200, the source satellite 300, the target satellite 301, and the user terminal 400 described above and, for example, illustrated in Figures 1, 2, 3, 4, 7, 8, 10, and/or 14.

In this example, although most of the process is the same or similar to the process described above and shown in Figure 8, the operation of UT 400 is different here after the antenna is moved. Because most of the steps and actions in process 1200 are the same or similar to those in process 800, those actions are not described here for the sake of brevity.

In this example, after the transmission of the last return link packet 1202 from UT 400 (if such a transmission occurs), UT 400 can terminate or suspend the return link and, at 1204, can begin buffering user data until the handoff is complete. In addition, at 1206, UT 400 can immediately (or after an appropriate delay) begin realigning the antenna or feed. In this example, upon completion of the realignment of the antenna/feed, at 1208, UT 400 can begin searching for a forward link transmitted from gateway 200 via target satellite 301. For example, UT 400 can monitor the time and frequency resources allocated for forward link transmissions from target satellite 301 as indicated in handoff message 1210.

At gateway 200, after receiving the last return link packet 1212 from UT 400 via source satellite 300, gateway 200 may employ an appropriate delay at 1214. For example, the delay may correspond to one or more parameters in handover message 1210 and/or handover confirmation message 1216. That is, gateway 200 may have or may determine information regarding the time required to move the antenna or feed at UT 400 from source satellite 300 to target satellite 301. In other examples, delay 1214 may be a fixed delay or any delay independent of the time required to move the antenna or feed at UT 400. In other examples, delay 1214 may be optional or may be avoided. After delay 1214, if such a delay occurs, gateway 200 may continue transmission on forward link 1218 to UT 400 via target satellite 301. At UT 400, upon receiving the first forward link packet at 1220, UT 400 may use the first forward link packet as a trigger to begin transmission 1222 of the return link (including any buffered return link data).

FIG13 is a flow diagram illustrating an exemplary process 1300 for satellite-to-satellite handoff according to aspects of the present disclosure, e.g., corresponding to the call flow diagram of FIG12. The handoff process 1300 may be performed by a UT shown in any of FIG1, 4, 7, 8, 10, 12, and/or 14. In one specific example, the UT may be UT 400 shown in FIG4, equipped with an antenna similar to antenna 600 shown in FIG6.

At block 1302, UT 400 may communicate with a gateway (e.g., gateway 200) via a first satellite (e.g., source satellite 300). For example, a forward link may flow from the gateway to the UT via the first satellite, and a return link may flow from the UT to the gateway via the first satellite.

At block 1304, UT 400 may receive a handover message from the gateway via the first satellite. Here, the handover message may include information sufficient for UT 400 to identify the target satellite and determine a time for handover from the first satellite to the second satellite. In other words, the handover message may identify the second satellite as the target satellite for handover, or may include appropriate parameters to enable UT 400 to realign its antenna toward the second satellite.

At block 1306, UT 400 may schedule a handoff from the first satellite to the second satellite based on the handoff message. Here, the handoff may be scheduled at a later time, for example, corresponding to an orbital pattern of LEO satellites in a LEO satellite communication network. In some examples, scheduling the handoff may include determining a direction for aligning an antenna at UT 400 toward the second satellite based on at least one of: information included in the handoff message, information received from a broadcast channel, or an ephemeris broadcast.

In response to the handover message, UT 400 may send a handover confirmation message to the gateway via the first satellite at block 1308. In some examples, the handover confirmation message may include an estimated time for realigning the antenna to the second satellite.

As shown in Figure 13, a period of time may elapse after the transmission of the handover confirmation message. That is, the transmission of the handover confirmation message may be performed independently of the time at which the actual handover occurs. Here, the time for the handover may correspond to the orbital pattern of the satellite, as indicated in the handover message.

At block 1310, UT 400 may receive a last forward link packet from the gateway via the first satellite. In some examples, the last forward link packet may be identified as being the last forward link packet, for example, by at least one of: a schedule or frame number included in a handover message, a signaling message received from the gateway, and/or an indication embedded in the last forward link packet.

At block 1312, UT 400 may transmit the last return link packet to the gateway via the first satellite. After transmission of the last return link packet, UT 400 may perform a handoff from the first satellite to the second satellite. That is, at block 1314, UT 400 may terminate or suspend return link transmission via the first satellite and may begin buffering return link data while realigning the antenna. Accordingly, at block 1316, UT 400 may realign the antenna from the first satellite to the second satellite.

At block 1318, UT 400 may search for a forward link from the gateway via the second satellite on the time and frequency resources reserved for the forward link, and UT 400 may receive the forward link at block 1320. Here, receipt of the first forward link packet may trigger UT 400 to initiate transmission of a return link to the gateway via the second satellite using the time and frequency resources reserved for return link transmission.

As described above, in aspects of the present disclosure, UT 400 may not receive a handoff control packet from the gateway during the time period between the last forward link packet transmission and the receipt of the first forward link packet.

Referring now to FIG14 , there is shown a call flow diagram of a fourth exemplary satellite-to-satellite handover process 1400. As shown, the satellite-to-satellite handover process 1400 may be performed by the first gateway 200, the second gateway 201, the source satellite 300, the target satellite 301, and the user terminal 400 described above, and as illustrated, for example, in FIG1 , 2, 3, 4, 7, 8, 10, and/or 12.

In this example, although most of the process is the same or similar to the process described above and shown in Figures 8 and 10, the operation of UT 400 is different here than after the antenna is moved. Because most of the steps and actions in process 1400 are the same or similar to those in processes 800 and 1000, those actions are not described here for the sake of brevity.

In this example, after the transmission of the last return link packet 1402 from UT 400 (if such a transmission occurs), UT 400 can terminate or suspend the return link and, at 1404, can begin buffering user data until the handoff is complete. In addition, at 1406, UT 400 can immediately (or after an appropriate delay) begin realigning the antenna or feed. In this example, upon completion of antenna/feed realignment, at 1408, UT 400 can begin searching for a forward link transmitted from the second gateway 201 via the target satellite 301. For example, UT 400 can monitor the time and frequency resources allocated for forward link transmissions from the target satellite 301 as indicated in the handoff message 1410.

At the first gateway 200, following receipt of the last return link packet 1412 from the UT 400 via the source satellite 300, the first gateway 200 may forward or transmit any packets intended for the UT 400 to the second gateway 201 at 1413. Furthermore, following transmission of the last forward link packet 1415, appropriate signaling and communications may occur to indicate to the infrastructure 106 that the second gateway 201 will be the node from which forward link data will be sent to the UT 400. Accordingly, at this point, at 1414, the second gateway 201 may begin buffering any forward link data that it may receive from the infrastructure 106 until the handoff is complete.

At 1417, the second gateway 200 may employ an appropriate delay. For example, the delay may correspond to one or more parameters in the handover message 1410 and/or the handover confirmation message 1416. That is, the first gateway 200 and/or the second gateway 201 may have or may determine information regarding the time required to move the antenna or feed at the UT 400 from the source satellite 300 to the target satellite 301. In other examples, the delay 1417 may be a fixed delay or any delay independent of the time required to move the antenna or feed at the UT 400. In other examples, the delay 1417 may be optional or may be avoided. After the delay 1417, if such a delay occurs, the second gateway 201 may continue transmission via the forward link 1418 to the UT 400 via the target satellite 301. At UT 400, upon receiving the first forward link packet at 1420, UT 400 may use the first forward link packet as a trigger to begin transmission on return link 1422 (including any buffered return link data).

FIG15 is a flow diagram illustrating an exemplary process 1500 for satellite-to-satellite handoff according to some aspects of the present disclosure, e.g., corresponding to the call flow diagram of FIG14. The handoff process 1500 may be performed by a UT shown in any of FIG1, 4, 7, 8, 10, 12, and/or 14. In one specific example, the UT may be UT 400 shown in FIG4, equipped with an antenna similar to antenna 600 shown in FIG6.

At block 1502, UT 400 may communicate with a first gateway (e.g., first gateway 200) via a first satellite (e.g., source satellite 300). For example, a forward link may flow from the first gateway to the UT via the first satellite, and a return link may flow from the UT to the first gateway via the first satellite.

At block 1504, UT 400 may receive a handover message from the first gateway via the first satellite. Here, the handover message may include information sufficient for UT 400 to identify the target satellite and determine a time for handover from the first satellite to the second satellite. In other words, the handover message may identify the second satellite as the target satellite for handover, or may include appropriate parameters to enable UT 400 to realign its antenna toward the second satellite.

At block 1506, UT 400 may schedule a handoff from the first satellite to the second satellite based on the handoff message. Here, the handoff may be scheduled at a later time, for example, corresponding to an orbital pattern of LEO satellites in a LEO satellite communication network. In some examples, scheduling the handoff may include determining a direction for aligning an antenna at UT 400 toward the second satellite based on at least one of: information included in the handoff message, information received from a broadcast channel, or an ephemeris broadcast.

In response to the handover message, UT 400 may send a handover confirmation message to the first gateway via the first satellite at block 1508. In some examples, the handover confirmation message may include an estimated time for realigning the antenna to the second satellite.

As shown in Figure 15, a period of time may elapse after the transmission of the handover confirmation message. That is, the transmission of the handover confirmation message may be performed independently of the time at which the actual handover occurs. Here, the time for the handover may correspond to the orbital pattern of the satellite, as indicated in the handover message.

At block 1510, UT 400 may receive a last forward link packet from the first gateway via the first satellite. In some examples, the last forward link packet may be identified as being the last forward link packet, for example, by at least one of: a schedule or frame number included in a handover message, a signaling message received from the first gateway, and/or an indication embedded in the last forward link packet.

At block 1512, UT 400 may transmit the last return link packet to the first gateway via the first satellite. After transmission of the last return link packet, UT 400 may perform a handoff from the first satellite to the second satellite. That is, at block 1514, UT 400 may terminate or suspend return link transmission to the first gateway via the first satellite and may begin buffering return link data while realigning the antenna. Accordingly, at block 1516, UT 400 may realign the antenna from the first satellite to the second satellite.

At block 1518, UT 400 may search for a forward link from the second gateway via the second satellite on the time and frequency resources reserved for the forward link, and UT 400 may receive the forward link at block 1520. Here, receipt of the first forward link packet may trigger UT 400 to initiate transmission of a return link to the second gateway via the second satellite using the time and frequency resources reserved for return link transmission.

As described above, in aspects of the present disclosure, UT 400 may not receive a handoff control packet from the first gateway or the second gateway during a time period between the last forward link packet transmission and the receipt of the first forward link packet.

FIG16 is a conceptual diagram 1600 illustrating a simplified example of a hardware implementation for an apparatus employing a processing circuit 1602 that can be configured to perform one or more functions disclosed herein. According to various aspects of the present disclosure, the processing circuit 1602 can be utilized to implement an element, or any portion of an element, or any combination of elements as disclosed herein. In various examples, the processing circuit 1602 can function as one or more of: a processor within the gateway controller 250 shown in FIG2 ; a processor within the controller 340 shown in FIG3 ; the control processor 420 shown in FIG4 ; and/or the processor 512 shown in FIG5 . The processing circuit 1602 can include one or more processors 1604 controlled by some combination of hardware and software modules. Examples of the processor 1604 include a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic device (PLD), a state machine, a sequencer, gating logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout the present disclosure. The one or more processors 1604 may include special-purpose processors that perform specific functions and may be configured, enhanced, or controlled by one of the software modules 1616. The one or more processors 1604 may be configured by a combination of software modules 1616 loaded during initialization, and further configured by loading or unloading one or more software modules 1616 during operation.

In the illustrated example, processing circuitry 1602 may be implemented using a bus architecture, generally represented by bus 1610. Bus 1610 may include any number of interconnecting buses and bridges, depending on the specific application and overall design constraints of processing circuitry 1602. Bus 1610 links together various circuits, including one or more processors 1604 and storage 1606. Storage 1606 may include memory devices and mass storage devices and may be referred to herein as computer-readable storage media and/or processor-readable storage media. Bus 1610 may also link various other circuits, such as timing sources, timers, peripherals, voltage regulators, and power management circuitry. Bus interface 1608 may provide an interface between bus 1610 and one or more transceivers 1612 (also referred to as line interface circuitry). A transceiver 1612 may be provided for each networking technology supported by the processing circuitry. In some cases, multiple networking technologies may share some or all of the circuitry or processing modules found in transceiver 1612. Each transceiver 1612 provides a means for communicating with various other devices over a transmission medium. Depending on the nature of the device, a user interface 1618 (e.g., keys, display, speaker, microphone, joystick) may also be provided and may be communicatively coupled to the bus 1610 directly or through the bus interface 1608.

The processor 1604 may be responsible for managing the bus 1610 and for general processing, which may include the execution of software stored in a computer-readable storage medium, which may include storage 1606. In this regard, the processing circuit 1602, including the processor 1604, may be used to implement any of the methods, functions, and techniques disclosed herein. The storage 1606 may be used to store data that is manipulated by the processor 1604 when executing the software, and the software may be configured to implement any of the methods disclosed herein.

One or more processors 1604 in the processing circuit 1602 can execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise, software should be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, algorithms, and the like. The software may reside in computer-readable form in the storage 1606 or in an external computer-readable storage medium. The external computer-readable storage medium and/or the storage 1606 may include non-transitory computer-readable storage media. By way of example, non-transitory computer-readable storage media include magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips), optical disks (e.g., compact discs (CDs) or digital versatile discs (DVDs)), smart cards, flash memory devices (e.g., "flash drives," cards, sticks, or key drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable medium for storing software and/or instructions that can be accessed and read by a computer. By way of example, computer-readable storage media and/or storage 1606 may also include carrier waves, transmission lines, and any other suitable medium for transmitting software and/or instructions that can be accessed and read by a computer. Computer-readable storage media and/or storage devices 1606 may reside in processing circuit 1602, in processor 1604, external to processing circuit 1602, or distributed across multiple entities including processing circuit 1602. The computer-readable storage medium and/or storage 1606 can be embodied in a computer program product. For example, the computer program product can include a computer-readable storage medium in packaging materials. Those skilled in the art will recognize that how best to implement the functionality described throughout this disclosure depends on the specific application and the overall design constraints imposed on the entire system.

Storage 1606 may maintain software maintained and/or organized in loadable code segments, modules, applications, programs, etc. (which may be referred to herein as software modules 1616). Each of software modules 1616 may include instructions and data that, when installed or loaded on processing circuitry 1602 and executed by one or more processors 1604, contribute to a runtime image 1614 that controls operations on the one or more processors 1604. When executed, specific instructions may cause processing circuitry 1602 to perform functions in accordance with certain methods, algorithms, and processes described herein.

Some of the software modules 1616 may be loaded during initialization of the processing circuit 1602, and these software modules 1616 may configure the processing circuit 1602 to perform the various functions disclosed herein. For example, some of the software modules 1616 may configure the internal devices and/or logic circuits 1622 of the processor 1604 and may manage access to external devices (e.g., the transceiver 1612, the bus interface 1608, the user interface 1618, timers, math coprocessors, etc.). The software modules 1616 may include a control program and/or an operating system that interacts with interrupt handlers and device drivers and controls access to various resources provided by the processing circuit 1602. Resources may include memory, processing time, access to the transceiver 1612, the user interface 1618, etc.

One or more processors 1604 of processing circuitry 1602 can be multifunctional, whereby some of software modules 1616 are loaded and configured to execute different functions or different instances of the same function. One or more processors 1604 can also be adapted to manage background tasks, such as those initiated in response to input from user interface 1618, transceiver 1612, and device drivers. To support the execution of multiple functions, one or more processors 1604 can be configured to provide a multitasking environment, whereby each of the multiple functions is implemented as a set of tasks serviced by one or more processors 1604 as needed or desired. In various examples, the multitasking environment can be implemented using a time-sharing program 1620 that transfers control of processor 1604 between different tasks, whereby each task returns control of one or more processors 1604 to the time-sharing program 1620 upon completion of any outstanding operations and/or in response to input, such as an interrupt. When a task has control of one or more processors 1604, the processing circuitry is effectively dedicated to the purpose addressed by the function associated with the control task. The time-sharing program 1620 may include an operating system, a main loop that transfers control on a round-robin basis, a function that allocates control of one or more processors 1604 based on the priority of the function, and/or an interrupt-driven main loop that responds to external events by providing control of one or more processors 1604 to a processing function.

Those skilled in the art will recognize that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips mentioned throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

In addition, it will be appreciated by those skilled in the art that the various illustrative logic blocks, modules, circuits and algorithmic steps described in conjunction with aspects disclosed herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits and steps have been generally described above according to their functions. Whether such functions are implemented in hardware or software depends on application-specific and the design constraints imposed on the entire system. Technicians can implement the described functions in different ways for each application-specific, but such implementation decisions should not be interpreted as causing deviations from the scope of this disclosure.

The methods, sequences, or algorithms described in conjunction with the aspects disclosed herein may be embodied directly in hardware, in software modules executed by a processor, or in a combination of the two. The software modules may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. In an alternative embodiment, the storage medium may be integrated into the processor.

Accordingly, one aspect of the present disclosure may include a non-transitory computer-readable medium embodying a method for operating a user terminal (UT) to perform a handoff from a first satellite to a second satellite, as described above with respect to Figures 8-15. The term "non-transitory" does not exclude any physical storage medium or memory, and in particular does not exclude dynamic memory (e.g., conventional random access memory (RAM)), but only excludes interpretations that the medium may be interpreted as a transient propagating signal.

Although the foregoing disclosure shows illustrative aspects, it should be noted that various changes and modifications may be made herein without departing from the scope of the appended claims. Unless expressly stated otherwise, the functions, steps, or actions of the method claims according to the aspects described herein do not need to be performed in any particular order. In addition, although elements may be described or declared in the singular, the plural form is intended unless a limitation to the singular form is expressly stated. Accordingly, the present disclosure is not limited to the examples illustrated, and any unit for performing the functions described herein is included in the aspects of the present disclosure.

Claims (26)

1. A method for operating a user terminal (UT) to perform a handover from a first satellite to a second satellite, comprising: Communicating with the first gateway on the forward and return links via the first satellite; The UT receives a handover message from the first gateway via the first satellite, wherein the handover message includes sufficient information for the UT to identify the second satellite for the handover and to determine the time for the handover from the first satellite to the second satellite; The handover from the first satellite to the second satellite is scheduled based on the identified second satellite and the determined time; and Perform the switch from the first satellite to the second satellite. The switching process includes: The final return-to-service link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned to utilize the second satellite, the return link continues by sending the first RSL packet to the second gateway via the second satellite. The UT is configured not to receive handover control packets from the first gateway or the second gateway during the time period between the last forward service link (FSL) packet transmission and the first RSL packet transmission. 2. The method of claim 1, wherein performing the handover includes performing the handover at a later time after the scheduling of the handover. 3. The method according to claim 1, wherein performing the switching comprises: Terminate the return link via the first satellite; Realign the antenna at the UT from the first satellite to the second satellite; and Initiate a transmission via the second satellite on the return link. 4. The method of claim 1, further comprising, after the handover, communicating with a second gateway via the second satellite. The first gateway is a different gateway from the second gateway. 5. The method of claim 1, further comprising determining the direction for aligning the antenna to the second satellite based on at least one of the following: information contained in the switching message, information received from a broadcast channel, ephemeris broadcast, or any combination thereof. 6. The method of claim 1, further comprising receiving a final forward servicing link (FSL) packet from the first gateway via the first satellite, wherein the final FSL packet is identified by at least one of the following: The scheduling or frame number included in the switching message; Signaling messages from the first gateway; Indications embedded in the final FSL group; or Any combination thereof. 7. The method according to claim 1, further comprising: In response to the handover message, a handover confirmation message is sent to the first gateway via the first satellite, wherein the handover confirmation message includes an estimated time for re-aligning the antenna to the second satellite. 8. The method of claim 1, wherein performing the switching comprises: Before re-aligning the antenna, the final Return to Service Link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned, the first RSL packet is sent to the second gateway via the second satellite, and the first forward servicing link (FSL) packet is received via the second satellite. The UT is configured not to receive handover control packets from the second gateway during the time period between the last RSL packet transmission and the first FSL packet transmission. 9. The method of claim 1, wherein performing the switching comprises: Terminate the return link via the first satellite; The antenna at the UT is redirected from the first satellite to the second satellite; Monitor the forward link via the second satellite according to the information in the switching message; and After receiving the forward link packet via the second satellite, a transmission is initiated on the return link via the second satellite. 10. A user terminal (UT) configured to perform a handover from a first satellite to a second satellite, comprising: Memory, which includes switching instructions; and A processor operatively coupled to the memory. The processor and the memory are configured by the switching instruction to perform the following operations: Communicating with the first gateway on the forward and return links via the first satellite; The UT receives a handover message from the first gateway via the first satellite, wherein the handover message includes sufficient information for the UT to identify the second satellite for the handover and to determine the time for the handover from the first satellite to the second satellite; The handover from the first satellite to the second satellite is scheduled based on the identified second satellite and the determined time; and Perform the switch from the first satellite to the second satellite. In order to perform the switching, the processor and the memory are further configured to perform the following operations: The final return-to-service link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned to utilize the second satellite, the return link continues by sending the first RSL packet to the second gateway via the second satellite. The UT is configured not to receive handover control packets from the first gateway or the second gateway during the time period between the last forward service link (FSL) packet transmission and the first RSL packet transmission. 11. The user terminal of claim 10, wherein the processor and the memory are further configured to perform the handover at a later time following the scheduling of the handover. 12. The user terminal of claim 10, wherein, in order to perform the switching, the processor and the memory are further configured to perform the following operations: Terminate the return link via the first satellite; Realign the antenna at the UT from the first satellite to the second satellite; and Initiate a transmission via the second satellite on the return link. 13. The user terminal of claim 10, wherein the processor and the memory are further configured to communicate with the second gateway via the second satellite after the handover. The first gateway is a different gateway from the second gateway. 14. The user terminal of claim 10, wherein the processor and the memory are further configured to determine the direction for aligning the antenna to the second satellite based on at least one of: information contained in the handover message, information received from a broadcast channel, ephemeris broadcast, or any combination thereof. 15. The user terminal of claim 10, wherein the processor and the memory are further configured to receive a final forward service link (FSL) packet from the first gateway via the first satellite, wherein the final FSL packet is identified by at least one of the following: The scheduling or frame number included in the switching message; Signaling messages from the first gateway; Indications embedded in the final FSL group; or Any combination thereof. 16. The user terminal of claim 10, wherein the processor and the memory are further configured to perform the following operations: In response to the handover message, a handover confirmation message is sent to the first gateway via the first satellite, wherein the handover confirmation message includes an estimated time for re-aligning the antenna to the second satellite. 17. The user terminal of claim 10, wherein, in order to perform the switching, the processor and the memory are further configured to perform the following operations: Before re-aligning the antenna, the final Return to Service Link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned, the first RSL packet is sent to the second gateway via the second satellite, and the first forward servicing link (FSL) packet is received via the second satellite. The UT is configured not to receive handover control packets from the second gateway during the time period between the last RSL packet transmission and the first FSL packet transmission. 18. The user terminal of claim 10, wherein, in order to perform the handover, the processor and memory are further configured as follows: Terminate the return link via the first satellite; The antenna at the UT is redirected from the first satellite to the second satellite; Monitor the forward link via the second satellite according to the information in the switching message; and After receiving the forward link packet via the second satellite, a transmission is initiated on the return link via the second satellite. 19. A user terminal (UT) configured to perform a handover from a first satellite to a second satellite, comprising: A unit for communicating with the first gateway via the first satellite on the forward link and the return link; A unit for receiving a handover message from the first gateway via the first satellite, wherein the handover message includes sufficient information for the UT to identify the second satellite for the handover and to determine the time for the handover from the first satellite to the second satellite; A unit for scheduling the handover from the first satellite to the second satellite based on the identified second satellite and the determined time; and The unit used to perform the switch from the first satellite to the second satellite. The unit for performing the switching is configured to perform the following operations: The final return-to-service link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned to utilize the second satellite, the return link continues by sending the first RSL packet to the second gateway via the second satellite. The UT is configured not to receive handover control packets from the first gateway or the second gateway during the time period between the last forward service link (FSL) packet transmission and the first RSL packet transmission. 20. The user terminal of claim 19, further comprising a unit for receiving a final forward servicing link (FSL) packet from the first gateway via the first satellite, wherein the final FSL packet is identified by at least one of the following: The scheduling or frame number included in the switching message; Signaling messages from the first gateway; Indications embedded in the final FSL group; or Any combination thereof. 21. The user terminal according to claim 19, further comprising: A unit for sending a handover confirmation message to the first gateway via the first satellite in response to the handover message. The switching confirmation message includes the estimated time for re-aligning the antenna with the second satellite. 22. The user terminal of claim 19, wherein the unit for performing the handover is configured to perform the following operations: Before re-aligning the antenna, the final Return to Service Link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned, the first RSL packet is sent to the second gateway via the second satellite, and the first forward servicing link (FSL) packet is received via the second satellite. The UT is configured not to receive handover control packets from the second gateway during the time period between the last RSL packet transmission and the first forward service link (FSL) packet transmission. 23. A non-transitory computer-readable medium comprising a plurality of instructions for causing a user terminal (UT) to perform a handover from a first satellite to a second satellite, the instructions causing the UT to perform the following operations: Communicating with the first gateway on the forward and return links via the first satellite; The UT receives a handover message from the first gateway via the first satellite, wherein the handover message includes sufficient information for the UT to identify the second satellite for the handover and to determine the time for the handover from the first satellite to the second satellite; The handover from the first satellite to the second satellite is scheduled based on the identified second satellite and the determined time; and Perform the switch from the first satellite to the second satellite. In order to perform the switching, the instruction causes the UT to perform the following operations: The final return-to-service link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned to utilize the second satellite, the return link continues by sending the first RSL packet to the second gateway via the second satellite. The UT is configured not to receive handover control packets from the first gateway or the second gateway during the time period between the last forward service link (FSL) packet transmission and the first RSL packet transmission. 24. The non-transitory computer-readable medium of claim 23, wherein the instructions further cause the UT to perform the following operations: The final forward service link (FSL) packet is received from the first gateway via the first satellite, wherein the final FSL packet is identified by at least one of the following: The scheduling or frame number included in the switching message; Signaling messages from the first gateway; Indications embedded in the final FSL group; or Any combination thereof. 25. The non-transitory computer-readable medium of claim 23, wherein the instructions further cause the UT to perform the following operations: In response to the handover message, a handover confirmation message is sent to the first gateway via the first satellite. The switching confirmation message includes the estimated time for re-aligning the antenna with the second satellite. 26. The non-transitory computer-readable medium of claim 23, wherein the instructions further cause the UT to perform the following operations: Before re-aligning the antenna, the final Return to Service Link (RSL) packet is sent to the first gateway via the first satellite; and After the antenna is re-aligned, the first RSL packet is sent to the second gateway via the second satellite, and the first forward servicing link (FSL) packet is received via the second satellite. The UT is configured not to receive handover control packets from the second gateway during the time period between the last RSL packet transmission and the first FSL packet transmission.