JP6595124B2 - Handoff for satellite communications - Google Patents

Description

This application is a provisional application No. 62 / 409,289 filed with the USPTO on October 17, 2016, and a non-provisional application filed with the USPTO on April 28, 2016. No. 15 / 141,641 and non-provisional application No. 15 / 498,388 filed with the United States Patent and Trademark Office on April 26, 2017, all of which are hereby incorporated by reference in their entirety. Embedded in the book.

  Various aspects described herein relate to satellite communications, and more specifically, but not exclusively, to handoffs for non-geostationary satellite communications.

  A satellite-based communication system may include a gateway and one or more satellites to relay communication signals between the gateway and one or more user terminals. The gateway is a ground station having an antenna for transmitting a signal to a communication satellite and receiving a signal from the communication satellite. A gateway is a communication link that uses satellites to connect user terminals to other user terminals or users of other communication systems such as the public switched telephone network, the Internet, and various public and / or private networks. I will provide a. Satellites are orbiting receivers and repeaters that are used to relay information.

  As long as the user terminal is within the “footprint” of the satellite, the satellite can receive signals from the user terminal and transmit signals to the user terminal. The satellite footprint is a geographical area on the surface within the satellite signal. Footprints are typically geographically divided into multiple “beams” through the use of antennas (for example, antennas may be used to form a fixed static beam or May be used to form a dynamically adjustable beam through a shaping technique). Each beam covers a specific geographic area within the footprint. The beams can be directed so that multiple beams from the same satellite cover the same specific geographic area. In addition, beams from multiple satellites can be directed to cover the same geographic area. The cell may configure the frequency of any forward link and / or the return link in the beam. If each beam uses only one frequency, the terms “cell” and “beam” may be interchangeable.

  Geostationary satellites have long been used for communication. Since a geostationary satellite is stationary relative to a given location on the earth, there is little timing shift and Doppler frequency shift in radio signal propagation between a communications transceiver on the earth and a geostationary satellite. However, geostationary satellites are limited to geosynchronous orbit (GSO), and GSO is a circle with a radius of about 42,164 km from the center of the earth, just above the equator, so the number of satellites that can be placed in GSO is limited.

  As an alternative to geostationary satellites, communication systems that utilize satellite placement in non-geostationary orbits, such as Low Earth Orbit (LEO), have been devised to provide communication coverage for the entire earth or at least most of the earth. In non-geostationary satellite-based systems, such as LEO satellite-based systems, the satellites move relative to ground-based communication devices such as gates or user terminals. Thus, at some point, the user terminal is handed off from one satellite to another. As a result, there is a need for techniques that allow user terminals to be handed off efficiently to the best available satellite.

  The following presents a simplified summary of such aspects so as to provide a basic understanding of some aspects of the present disclosure. This summary is not an extensive overview of all contemplated features of the disclosure, and it does not identify key or critical elements of all aspects of the disclosure, but any or all aspects of the disclosure It does not define the scope of Its sole purpose is to present various concepts of some aspects of the disclosure in a simplified form as a prelude to the more detailed description that is presented later.

  In one aspect, the present disclosure identifies a time associated with a particular entry of a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for device handoff; Determining whether to send a request for an updated set of handoff entries based on the specified time and, if the decision is to send a request, a request for an updated set of handoff entries A method for communication comprising the steps of:

  In some aspects, the set of handoff entries may include (eg, may be) an idle mode handoff table. In some aspects, the time may include a start time for handoff to one satellite of the set of satellites. In some aspects, that particular entry may include the last entry in the set of handoff entries. In some aspects, that set of satellites may be for idle mode operation of the device. In some aspects, this time may indicate when the device should handoff to one satellite in the set of satellites while the device is in idle mode. In some aspects, the set of handoff entries may specify a time for a device in idle mode to handoff to each satellite in the set of satellites. In some aspects, the set of handoff entries may include a time for each satellite to be handed off to a satellite by a device in idle mode. In some aspects, the request may be communicated when the device establishes a wireless connection with the terrestrial network. In some aspects, the apparatus may include (eg, may be) a user terminal. In some aspects, the request may be sent to the terrestrial network.

  In one aspect, the present disclosure provides an apparatus configured for communication, including a memory and a processor coupled to the memory. The processor and memory identify a time associated with a particular entry of the set of handoff entries, wherein the set of handoff entries identifies a set of satellites for handoff of the device; Based on the specified time, determine whether to send a request for an updated set of handoff entries, and if the decision is to send a request, request for an updated set of handoff entries. Configured to transmit.

  In some aspects, the set of handoff entries may include an idle mode handoff table, and the idle mode handoff table may include a time for each satellite in apparatus in idle mode to handoff to the satellite. In some aspects, the processor and memory may be further configured to send an indication of that time along with sending the request. In some aspects, the processor and memory may be further configured to send an indication of a validity time associated with that set of handoff entries along with the sending of the request. In some aspects, the processor and memory further receive an updated set of handoff entries after sending the request and are identified by the updated set of handoff entries at the time indicated by the updated set of handoff entries. Can be configured to handoff to a satellite to be operated. In some aspects, the processor and the memory may be further configured to receive an indication of at least one carrier frequency that a next cell providing coverage for the device will use to transmit. The handoff to the satellite identified by the updated set of handoff entries may occur at at least one carrier frequency. In some aspects, the processor and memory may be further configured to determine device location information and send the location information along with the transmission of the request.

  In one aspect, the present disclosure provides an apparatus configured for communication. The device is identified as means for identifying a time associated with a particular entry in the set of handoff entries, wherein the set of handoff entries identifies a set of satellites for handoff of the device. A means for determining whether to send a request for an updated set of handoff entries based on the determined time, and a request for an updated set of handoff entries if the decision is to send a request. Means for transmitting.

  In some aspects, the means for transmitting may be configured to transmit an indication of that time along with the transmission of the request. In some aspects, the means for transmitting may be configured to transmit an indication of a valid time associated with that set of handoff entries along with the transmission of the request. In some aspects, the apparatus can provide a means for receiving an updated set of handoff entries after sending a request, and an updated set of handoff entries at a time indicated by the updated set of handoff entries. Means for handing off the device to the identified satellite. In some aspects, the means for receiving may be configured to receive an indication of at least one carrier frequency that a next cell providing coverage for the device will use to transmit. Yes, a handoff to a satellite identified by an updated set of handoff entries may occur at at least one carrier frequency. In some aspects, the apparatus may include means for determining the position information of the apparatus, and the means for transmitting may be further configured to transmit the position information along with the transmission of the request. .

  In one aspect, this disclosure identifies a time associated with a particular entry of a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for device handoff And determining whether to send a request for an updated set of handoff entries based on the specified time and, if the decision is to send a request, an updated set of handoff entries A non-transitory computer-readable medium storing computer-executable code, including code for performing a request for

  In one aspect, this disclosure identifies the amount of valid entries in a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for device handoff; and Determining whether to send a request for an updated set of handoff entries based on the amount received, and if the decision is to send a request, send a request for the updated set of handoff entries And providing a method for communication.

  In some aspects, determining whether to send a request for an updated set of handoff entries may include determining whether the set of handoff entries includes only one valid entry. In some aspects, the request may be communicated when the device establishes a wireless connection with the terrestrial network. In some aspects, the set of handoff entries may specify a time for a device in idle mode to handoff to each satellite in the set of satellites.

  In one aspect, the present disclosure provides an apparatus configured for communication, including a memory and a processor coupled to the memory. The processor and the memory are identified to identify the amount of valid entries in the set of handoff entries, wherein the set of handoff entries identifies a set of satellites for device handoff. To determine whether to send a request for an updated set of handoff entries based on the amount received and, if the decision is to send a request, send a request for the updated set of handoff entries Configured to do things.

  In some aspects, the processor and memory further receive an updated set of handoff entries after sending the request and are identified by the updated set of handoff entries at the time indicated by the updated set of handoff entries. Can be configured to handoff to a satellite to be operated. In some aspects, the processor and the memory may be further configured to receive an indication of at least one carrier frequency that a next cell providing coverage for the device will use to transmit. The handoff to the satellite identified by the updated set of handoff entries may occur at at least one carrier frequency. In some aspects, the processor and memory may be further configured to determine device location information and send the location information along with the transmission of the request.

  In one aspect, an apparatus configured for communication is provided. The apparatus is a means for identifying the amount of valid entries in the set of handoff entries, wherein the set of handoff entries identifies a set of satellites for handoff of the apparatus, and the identified amount And a means for deciding whether to send a request for an updated set of handoff entries, and sending a request for the updated set of handoff entries if the decision is to send a request Means.

  In some aspects, the apparatus can provide a means for receiving an updated set of handoff entries after sending a request, and an updated set of handoff entries at a time indicated by the updated set of handoff entries. Means for handing off the device to the identified satellite. In some aspects, the means for receiving may be configured to receive an indication of at least one carrier frequency that a next cell providing coverage for the device will use to transmit. Yes, a handoff to a satellite identified by an updated set of handoff entries may occur at at least one carrier frequency. In some aspects, the device may include means for determining the location information of the device, and the means for transmitting may be configured to transmit the location information along with the transmission of the request.

  In one aspect, the disclosure is to identify an amount of valid entries in a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for device handoff; and Determining whether to send a request for an updated set of handoff entries based on the specified amount, and if the decision is to send a request, a request for an updated set of handoff entries A non-transitory computer-readable medium having stored thereon computer-executable code, including code for performing the transmission.

  In one aspect, the disclosure is identified with identifying a time of validity associated with a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for handoff of another device. Determining whether to send an updated set of handoff entries based on the valid time, and if the decision is to send an updated set of handoff entries, an updated set of handoff entries A method for communication comprising the steps of:

  In some aspects, the valid time indicates the length of time that the set of handoff entries may be valid. In some aspects, identifying the validity time may include receiving an indication of the validity time. In some aspects, determining the validity time includes receiving an indication of a time associated with a particular entry of the set of handoff entries, and determining an expiration time based on the received indication. obtain. In some aspects, identifying valid times may include determining a time associated with the last valid entry in the set of handoff entries. In some aspects, the set of handoff entries may include the last set of handoff entries sent by the device to other devices. In some aspects, the device may include (eg, may be) a terrestrial network. In some aspects, an updated set of handoff entries may be sent to the user terminal.

  In one aspect, the present disclosure provides an apparatus configured for communication, including a memory and a processor coupled to the memory. The processor and memory identify a valid time associated with a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for handoff of another device, and identified Based on the validity time, determine whether to send an updated set of handoff entries, and if the decision is to send an updated set of handoff entries, Configured to transmit.

  In some aspects, the processor and memory may be further configured to receive location information of other devices. In some aspects, the processor and the memory may be further configured to generate an updated set of handoff entries based on the location information, wherein the updated set of handoff entries is transmitted to other devices. Sometimes. In some aspects, the processor and memory may be further configured to receive location information of other devices, and the determination of whether to send an updated set of handoff entries further includes location information. May be based. In some aspects, the processor and memory may be further configured to receive location information of other devices. In some aspects, the processor and memory may be further configured to determine other device movements based on the location information, further determining whether to send an updated set of handoff entries. May be based on the movement of other devices. In some aspects, the processor and memory further receive location information of other devices, determine other device motion based on the location information, and determine how many updated handoffs are based on other device motion. It may be configured to determine whether to send an entry.

  In one aspect, the present disclosure provides an apparatus configured for communication. An apparatus is a means for identifying a valid time associated with a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for handoff of another apparatus, and the identified valid time Based on the means for determining whether to send an updated set of handoff entries and, if the decision is to send an updated set of handoff entries, an updated set of handoff entries, Means for transmitting.

  In some aspects, an apparatus may include means for receiving location information of another device and means for generating an updated set of handoff entries based on the location information, The updated set may be sent to other devices. In some aspects, a device may include means for receiving location information of another device, and the determination of whether to send an updated set of handoff entries may further be based on the location information. is there. In some aspects, the device may include means for receiving location information of the other device and means for determining movement of the other device based on the location information, and updating the handoff entry The determination of whether to transmit the configured set may further be based on the movement of other devices. In some aspects, a device may include means for receiving position information of another device, means for determining movement of the other device based on the position information, and number of devices based on movement of the other device. Means for determining whether to send the updated handoff entry.

  In one aspect, this disclosure identifies a valid time associated with a set of handoff entries, wherein the set of handoff entries identifies a set of satellites for handoff of another device; Based on the specified validity time, it is determined whether to send an updated set of handoff entries, and if the decision is to send an updated set of handoff entries, the handoff entry is updated. A non-transitory computer-readable medium storing computer-executable code for a device is provided, including code for transmitting a set.

  These and other aspects of the disclosure will be more fully understood when the following detailed description is considered. Other aspects, features, and implementations of the present disclosure will become apparent to those skilled in the art upon review of the following description of specific implementations of the present disclosure in conjunction with the accompanying figures. Although features of the present disclosure may be discussed with respect to several implementations and figures below, all implementations of the present disclosure include one or more of the advantageous features described herein. obtain. In other words, one or more implementations may be described as having a number of advantageous features, but one or more of such features may also be described in the present disclosure as described herein. Can be used according to various implementations. Similarly, although some implementations may be discussed below as device, system, or method implementations, it should be understood that such implementations may be implemented with various devices, systems, and methods. .

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

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

1 is a block diagram of an exemplary communication system in accordance with certain aspects of the present disclosure. FIG. 2 is a block diagram of an example of the terrestrial network (GN) of FIG. 1 in accordance with certain aspects of the present disclosure. FIG. 2 is a block diagram of an example of the satellite of FIG. 1 according to some aspects of the present disclosure. FIG. 2 is a block diagram of an example of the user terminal of FIG. 1 according to some aspects of the present disclosure. FIG. 2 is a block diagram of an example of the user equipment of FIG. 1 according to some aspects of the present disclosure. FIG. 6 is a block diagram illustrating an example transmitter device and receiver device in accordance with certain aspects of the present disclosure. 1 is a block diagram of an exemplary communication system in accordance with certain aspects of the present disclosure. FIG. 3 illustrates an example of communicating idle mode information according to some aspects of the present disclosure. FIG. 6 illustrates an example of an idle mode handoff in accordance with certain aspects of the present disclosure. 1 is a block diagram of an exemplary communication system in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example of handoff signaling between satellites in accordance with certain aspects of the present disclosure. FIG. 6 illustrates another example of inter-satellite handoff signaling in accordance with certain aspects of the present disclosure. FIG. 6 illustrates an example of feeder link switching in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example of satellite indication error in accordance with certain aspects of the present disclosure. FIG. 3 illustrates an example call flow for non-random access based BxP handoff according to some aspects of the present disclosure. FIG. 6 illustrates an example call flow for non-random access based BxP handoff using user terminal (UT) measurements in accordance with certain aspects of the present disclosure. FIG. 3 illustrates an example call flow for a random access based BxP handoff in accordance with certain aspects of the present disclosure. FIG. 6 illustrates an example call flow for random access based BxP handoff using UT measurements in accordance with certain aspects of the present disclosure. FIG. 6 illustrates an example call flow for random access based BxP handoff using UT measurements in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example AxP handoff call flow in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example AxP handoff call flow in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example AxP handoff call flow in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example call flow for a radio link failure in accordance with certain aspects of the present disclosure. FIG. 3 illustrates an example of generating and using satellite and cell transition tables according to some aspects of the present disclosure. FIG. 6 illustrates an example of using satellite and cell transition tables in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example of signaling user terminal capabilities in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example of using user terminal capabilities in accordance with certain aspects of the present disclosure. FIG. 7 illustrates an example of signaling user terminal location information according to some aspects of the present disclosure. FIG. 4 is a diagram illustrating an example of using user terminal location information according to some aspects of the present disclosure. FIG. 6 illustrates an example user terminal handoff operation in accordance with certain aspects of the present disclosure. FIG. 7 illustrates an example of a GN handoff operation according to some aspects of the present disclosure. FIG. 6 illustrates another example of inter-satellite handoff signaling in accordance with certain aspects of the present disclosure. FIG. 4 illustrates an example of signaling ephemeris information according to some aspects of the present disclosure. FIG. 6 illustrates an example of a radio link failure operation in accordance with certain aspects of the present disclosure. FIG. 6 illustrates an example measurement gap related operation in accordance with certain aspects of the present disclosure. FIG. 9 illustrates another example of a measurement gap related operation according to some aspects of the present disclosure. FIG. 7 illustrates an example of user queue related operations according to some aspects of the present disclosure. FIG. 7 illustrates an example of a random access related operation according to some aspects of the present disclosure. FIG. 6 is a block diagram illustrating an example hardware implementation for an apparatus (eg, an electronic device) that can support communication in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an exemplary communication process in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an exemplary communication process in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an exemplary communication process in accordance with certain aspects of the present disclosure. FIG. 6 is a block diagram illustrating an example hardware implementation for an apparatus (eg, an electronic device) that can support communication in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an exemplary communication process in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an exemplary communication process in accordance with certain aspects of the present disclosure. FIG. 2 is a block diagram of an example hardware implementation for an apparatus (eg, an electronic device) that can support satellite-related communications in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an example process involved in generating satellite handoff information in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an example process involved in generating satellite and cell transition information in accordance with certain aspects of the present disclosure. FIG. 6 is a block diagram of an example hardware implementation for another apparatus (eg, an electronic device) that can support satellite-related communications in accordance with certain aspects of the present disclosure. 6 is a flowchart illustrating an example of a process involved in a handoff according to some aspects of the present disclosure. 6 is a flowchart illustrating an example of a process involved in a handoff according to some aspects of the present disclosure.

  Various aspects of the disclosure relate to an idle mode handoff for a user terminal (UT). In some scenarios, an idle UT requests idle mode handoff information from the terrestrial network (GN). The idle mode handoff information may include, for example, a start time for a set of satellites, each specific start time indicating when an idle UT can handoff to the corresponding satellite. In some aspects, an idle UT may be idle when the idle UT has a defined number of valid entries remaining in the idle mode handoff table (e.g., one unexpired entry). A request for mode handoff information may be sent to the GN. In some aspects, an idle UT may send a request for idle mode handoff information to the GN based on a time associated with a particular entry (eg, the last entry) in the idle mode handoff table. In some aspects, the idle UT may send a request for idle mode handoff information to the GN based on the validity time of the idle mode handoff table. In some aspects, an idle UT may send a request for idle mode handoff information to the GN when the idle UT establishes a wireless connection with the GN. In some aspects, the GN autonomously sends idle mode handoff information to the idle UT when the idle UT establishes a wireless connection with the GN (e.g., without a request from the idle UT). Can be sent.

  Aspects of the present disclosure are described in the following description and related drawings directed to specific embodiments. Alternate embodiments may be devised without departing from the scope of the present disclosure. In addition, well-known elements are not described in detail or are omitted so as not to obscure the relevant details of the present disclosure.

  FIG. 1 illustrates a satellite communication system 100, including a plurality of satellites in non-geostationary orbit, e.g., low earth orbit (LEO) (although only one satellite 300 is shown for clarity of illustration) A terrestrial network 200 that communicates (e.g., corresponding to a satellite gateway or satellite network portal), a plurality of UTs 400 and 401 that communicate with satellites 300, and a plurality of user equipments that communicate with UTs 400 and 401, respectively (UE ) Examples of 500 and 501 are shown. Each UE 500 or 501 can be a user device such as a mobile device, phone, smartphone, tablet, laptop computer, computer, wearable device, smart watch, audiovisual device, or any device that includes the ability to communicate with UT. . In addition, UE 500 and / or UE 501 may be a device (eg, access point, small cell, etc.) used to communicate with one or more end user devices. In the example shown in FIG. 1, 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 are separate bidirectional access links. Communicate with each other via In another implementation, one or more additional UEs (not shown) may be configured to only receive and thus communicate with the UT using only the forward access link. In another implementation, one or more additional UEs (not shown) may also communicate with UT400 or UT401. Alternatively, the UT and the corresponding UE may be an integral part of a single physical device such as, for example, a mobile phone with a built-in satellite transceiver and antenna for communicating directly with a satellite.

  The GN 200 may have access to the Internet 108 or to one or more other types of public networks, semi-private networks, or private networks. In the example shown in FIG. 1, the GN 200 is in communication with an infrastructure 106, which accesses the Internet 108, or one or more other types of public, semi-private, or private networks. It is possible. The GN 200 may also be coupled to various types of communication backhaul including, for example, a fixed line network such as a fiber optic network or a public switched telephone network (PSTN) 110. Further, in alternative implementations, the GN 200 interfaces with the Internet 108, the PSTN 110, or one or more other types of public, semi-private, or private networks without using the infrastructure 106. obtain. Still further, GN 200 may communicate with other GNs, such as GN 201, through infrastructure 106, or alternatively, may be configured to communicate with GN 201 without using infrastructure 106. Infrastructure 106 may be wholly or partly network control center (NCC), satellite control center (SCC), wired and / or wireless core network, and / or satellite communication system 100 operation and / or satellite communication system 100. Any other component or system used to assist in communication with the device.

  Communication between satellite 300 and GN 200 in both directions is referred to as a feeder link, and communication between the satellite and each of UTs 400 and 401 in both directions is referred to as a service link. A single path from satellite 300 to a ground station, which may be one of GN200 or UT400 and 401, may be generally referred to as the downlink. A single path from the ground station to the satellite 300 may be generally referred to as the uplink. In addition, as shown, the signal may have general directionality, such as a forward link and a return link (or reverse link). Thus, a communication link in the direction starting from GN200 and passing through satellite 300 and ending in UT400 is called a forward link, and a communication link starting in UT400 and going through satellite 300 and ending in GN200 is called a return or reverse link . Accordingly, in FIG. 1, the signal path from the GN 200 to the satellite 300 is named “forward feeder link” 112, while the signal path from the satellite 300 to the GN 200 is named “return feeder link” 114. Similarly, in FIG. 1, the signal path from each UT 400 or 401 to the satellite 300 is named “return service link” 116, while the signal path from the satellite 300 to each UT 400 or 401 is “forward service link”. It ’s named 118.

  The UT 401 handoff controller 122 and the GN 200 handoff controller 124 cooperate to control the UT 401 handoff from one satellite or cell to another. Other components of the satellite communication system 100 may also include a corresponding handoff controller. For example, other GNs, satellites, and UTs (not shown) may include corresponding controllers. However, to reduce the complexity of FIG. 1, handoff controllers are shown for UT 401 and GN 200 only.

  The UT 401 handoff controller 122 transmits UT information (eg, including UT location information and / or UT capability information) to the GN 200 handoff controller 124 via the satellite 300 (eg, via signaling 126). In addition, handoff controller 122 includes a handoff information request controller 136 that determines whether a handoff information request is also sent to handoff controller 124 of GN 200 (eg, via signaling 126).

  The handoff controller 124 includes a handoff information generator 130 that generates handoff information (eg, a handoff table) indicating the timing of UT401 handoff. In some aspects, handoff information generator 130 is based at least in part on UT information, satellite position over time (obtained from ephemeris data), satellite cell patterns, and satellite cell on and off schedules. Handoff information may be generated. Handoff controller 124 also includes a handoff information transmission controller 132 that determines whether to transmit handoff information 134 to handoff controller 122 via current satellite 300. In some aspects, handoff information transmission controller 132 may transmit handoff information 134 in response to a handoff information request from UT 401.

  Handoff controller 122 receives handoff information 134 via current satellite 300 and maintains a local copy of handoff information (eg, handoff table) 138. Handoff controller 122 can then control UT401 handoff based on handoff information 138.

  In some implementations, the satellite communication system 100 manages idle mode handoff information. For example, the handoff controller 124 may determine (eg, generate) idle mode handoff information and send the idle mode handoff information to the handoff controller 122. In some aspects, the handoff controller 124 can receive UT information (eg, UT position information) from the UT 401 and manages idle mode handoff information based on the UT information. In some aspects, handoff controller 122 may receive and manage a local copy of idle mode handoff information.

  FIG. 2 is an exemplary block diagram of the GN 200, which may also apply to the GN 201 of FIG. GN200 includes several antennas 205, RF subsystem 210, digital subsystem 220, public switched telephone network (PSTN) interface 230, local area network (LAN) interface 240, GN interface 245, and GN controller 250. It is shown. RF subsystem 210 is coupled to antenna 205 and digital subsystem 220. Digital subsystem 220 is coupled to PSTN interface 230, LAN interface 240, and GN interface 245. The GN controller 250 is coupled to the RF subsystem 210, the digital subsystem 220, the PSTN interface 230, the LAN interface 240, and the GN interface 245.

  An 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 the forward feeder link 301F and return feeder link 301R. The communication signal can be received from the satellite 300 via the. Although not shown for brevity, 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 (eg, a mixer) for amplifying and downconverting received communication signals in a well-known manner, respectively. In addition, each receive chain may include an analog-to-digital converter (ADC) for converting received communication signals from analog signals to digital signals (eg, for processing by digital subsystem 220). Each transmission chain may include an upconverter (eg, a mixer) and a power amplifier (PA) for upconverting and amplifying communication signals to be transmitted to the satellite 300, respectively, in a well-known manner. In addition, each transmit chain may include a digital-to-analog converter (DAC) for converting digital signals received from the digital subsystem 220 into analog signals to be transmitted to the satellite 300.

  The RF controller 214 may be used to control various aspects of several RF transceivers 212 (eg, carrier frequency selection, frequency and phase calibration, gain settings, etc.). The antenna controller 216 may control various aspects of the antenna 205 (eg, beamforming, beam steering, gain setting, frequency adjustment, 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 can 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, the PSTN interface 230 and / or the LAN interface The communication signal received from 240 can be processed and the processed communication signal can be forwarded to the RF subsystem 210.

  Each digital receiver module 222 may correspond to a signal processing element used to manage communication between the GN 200 and the UT 400. One of the receive chains of the RF transceiver 212 can provide input signals to multiple digital receiver modules 222. Several digital receiver modules 222 may be used to accept all of the satellite beams being handled at any given time and possible diversity mode signals. Although not shown for brevity, each digital receiver module 222 may include one or more digital data receivers, searcher receivers, and diversity combiner and decoder circuits. The searcher receiver may be used to search for the appropriate diversity mode of the carrier signal, and may be used to search for a pilot signal (or other relatively unchanged pattern strong signal) .

  The digital transmitter module 224 may process signals to be transmitted to the UT 400 via the satellite 300. Although not shown for brevity, each digital transmitter module 224 may include a transmission modulator that modulates data for transmission. The transmit power of each transmit modulator is required to (1) apply the lowest level of power for the purpose of interference reduction and resource allocation, and (2) compensate for transmit path attenuation and other path transfer characteristics. Can be controlled by a corresponding digital transmit power controller (not shown for brevity) that can apply an appropriate level of power when done.

  A control processor 228 coupled to the digital receiver module 222, the digital transmitter module 224, and the baseband processor 226 includes, but is not limited to, signal processing, timing signal generation, power control, handoff control, diversity combining, and systems Command and control signals may be provided to provide functions such as an interface.

  The control processor 228 may also control pilot generation and power, synchronization, and coupling (not shown for brevity) to the paging channel signal and its transmit power controller. A pilot channel is a signal that is not modulated by data and may use repetitive unchanging patterns or unchanging frame structure type (pattern) or tone type inputs. For example, the orthogonal functions used to form the channel for the pilot signal are generally well known, such as constant values such as all 1s or all 0s, or structured patterns interspersed with 1s and 0s. Have a repetitive pattern.

  Baseband processor 226 is well known in the art and will not be described in detail herein. For example, the baseband processor 226 may include a variety of known elements such as (but not limited to) a coder, a data modem, and digital data switching and storage components.

  The PSTN interface 230 may provide communication signals to and receive communication signals from the external PSTN, either directly or through additional infrastructure 106, as shown in FIG. The LAN interface 230 is well known in the art and will not be described in detail herein. In other implementations, the PSTN interface 230 may be omitted or replaced by any other suitable interface that connects the GN 200 to a terrestrial network (eg, the Internet).

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

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

  Overall GN control may be provided by the GN controller 250. The GN controller 250 may plan and control the use of the resources of the satellite 300 by the GN 200. For example, the GN controller 250 may analyze trends, generate traffic plans, allocate satellite resources, monitor (or track) satellite locations, and monitor GN 200 and / or satellite 300 performance. The GN controller 250 also maintains and monitors the orbit of the satellite 300, relays satellite usage information to the GN 200, tracks the location of the satellite 300, and / or adjusts the settings of various channels of the satellite 300, To a satellite controller (not shown for brevity).

  In the exemplary implementation shown in FIG. 2, the GN controller 250 includes a local time, frequency, and location reference 251 that includes an RF subsystem 210, a digital subsystem 220, and / or an interface 230, 240 and 245 may be provided with local time or frequency information. The time or frequency information may be used to synchronize the various components of the GN 200 with each other and / or with the satellite 300. Local time, frequency, and location criteria 251 may also provide satellite 300 location information (eg, ephemeris data) to various components of GN 200. Further, although illustrated in FIG. 2 as being included in the GN controller 250, in other implementations, the local time, frequency, and location criteria 251 may be included in the GN controller 250 (and / or the digital subsystem 220). And a separate subsystem coupled to one or more of the RF subsystems 210).

  Although not shown in FIG. 2 for simplicity, the GN controller 250 may also be coupled to a network control center (NCC) and / or a satellite control center (SCC). For example, the GN controller 250 may allow the SCC to communicate directly with the satellite 300, eg, retrieve ephemeris data from the satellite 300. The GN controller 250 is also suitable for the GN controller 250 to properly target the antenna 205 (e.g., of the appropriate satellite 300), schedule beam transmissions, coordinate handoffs, and various other well known Processed information (eg, from SCC and / or NCC) may be received that enables the function to be performed.

  The GN controller 250 is one of processing circuitry 232, a memory device 234, or a handoff controller 236 that independently or cooperatively performs handoff information related operations for the GN200 as taught herein. Multiple may be included. In certain exemplary implementations, the processing circuit 232 is configured (eg, programmed) to perform some or all of these operations. In another exemplary implementation, processing circuit 232 (eg, in the form of a processor) executes code stored in memory device 234 to perform some or all of these operations. In another exemplary implementation, handoff controller 236 is configured (eg, programmed) to perform some or all of these operations. Although illustrated in FIG. 2 as being included in the GN controller 250, in other implementations, one or more of the processing circuitry 232, memory device 234, or handoff controller 236 are in the GN controller 250 (and It may be a separate subsystem coupled to (or to one or more of digital subsystem 220 and RF subsystem 210).

  FIG. 3 is an exemplary block diagram of satellite 300 for illustrative purposes only. It will be appreciated that specific satellite configurations can vary greatly and may or may not include on-board processing. Furthermore, although shown as a single satellite, two or more satellites using inter-satellite communications may provide a functional connection between the GN 200 and the UT 400. The present disclosure is not limited to any particular satellite configuration, and any satellite or combination of satellites that can provide a functional connection between the GN200 and the UT400 can be considered within the scope of the present disclosure. Will be understood. In one example, satellite 300 includes forward transponder 310, return transponder 320, oscillator 330, controller 340, forward link antennas 351 and 352 (1) -352 (N), and return link antennas 362 and 361 (1) -361. It is shown as including (N). A forward transponder 310 capable of processing a communication signal in a corresponding channel or frequency band includes a first band-pass filter 311 (1) to 311 (N), respectively, a first low-noise amplifier (LNA) 312. (1) to 312 (N), one each of the frequency converters 313 (1) to 313 (N), each of the second LNA 314 (1) to 314 (N), each of the second One each of bandpass filters 315 (1) -315 (N) and one each of power amplifiers (PA) 316 (1) -316 (N) may be included. Each of PA 316 (1) -316 (N) is coupled to a respective one of antennas 352 (1) -352 (N), as shown in FIG.

  In each of the respective forward paths FP (1) to FP (N), the first bandpass filter 311 passes a signal component having a frequency in the channel or frequency band of the respective forward path FP, Filter signal components having frequencies outside the channel or frequency band of each forward path FP. Accordingly, the passband of the first bandpass filter 311 corresponds to the width of the channel associated with each forward path FP. The first LNA 312 amplifies the received communication signal to a level appropriate for processing by the frequency converter 313. The frequency converter 313 converts the frequency of the communication signal in each forward path FP (for example, to a frequency suitable for transmission from the satellite 300 to the UT 400). The second LNA 314 amplifies the frequency-converted communication signal, and the second bandpass filter 315 filters signal components having frequencies outside the associated channel width. The PA 316 amplifies the filtered signal to a power level suitable for transmission to the UT 400 via each antenna 352. The return transponder 320 including a certain number (N) of return paths RP (1) to RP (N) communicates communication signals from the UT 400 along the return service link 302R via the antennas 361 (1) to 361 (N). The signal is received and a communication signal is transmitted to the GN 200 along the return feeder link 301R via one or more of the antennas 362. Each of the return paths RP (1) to RP (N) that can process communication signals in the corresponding channel or frequency band may be coupled to one of the antennas 361 (1) to 361 (N), respectively. , One of each of the first bandpass filters 321 (1) to 321 (N), one of each of the first LNAs 322 (1) to 322 (N), the frequency converter 323 (1) to 323 (N) Each of the second LNAs 324 (1) -324 (N) and each of the second bandpass filters 325 (1) -325 (N).

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

  Oscillator 330, which can be any suitable circuit or device that generates an oscillation signal, provides forward local oscillator signal LO (F) to frequency converters 313 (1) -313 (N) of forward transponder 310; Return local oscillator signal LO (R) is provided to frequency converters 323 (1) -323 (N) of return transponder 320. For example, the LO (F) signal is frequency converted to convert the communication signal from the frequency band associated with signal transmission from GN200 to satellite 300 to the frequency band associated with signal transmission from satellite 300 to UT400. May be used by vessels 313 (1) -313 (N). The LO (R) signal is a frequency converter 323 for converting the communication signal from the frequency band associated with the transmission of the signal from the UT 400 to the satellite 300 to the frequency band associated with the transmission of the signal from the satellite 300 to the GN 200. (1) to 323 (N) can be used.

  Controller 340 coupled to forward transponder 310, return transponder 320, and oscillator 330 may control various operations of satellite 300, including (but not limited to) channel allocation. In one aspect, the controller 340 may include processing circuitry 364 (eg, a processor) coupled to memory (eg, memory device 366). The memory, when executed by the processing circuit 364, stores instructions that cause the satellite 300 to perform operations including, but not limited to, operations described herein (e.g., non-transitory computer readable media (e.g., One or more non-volatile memory elements, such as EPROM, EEPROM, flash memory, hard drive, etc.

  FIG. 4 is an exemplary block diagram of a UT 400 or UT 401 for illustrative purposes only. It should be understood that the specific UT configuration can vary greatly. Thus, the present disclosure is not limited to any particular UT configuration and any UT capable of providing a functional connection between the satellite 300 and the UE 500 or 501 is considered to be within the scope of the present disclosure. Can be made.

  UT can be used in various applications. In some scenarios, the UT may provide a cellular backhaul. In this case, the UT may have a relatively large antenna and / or multiple antennas (eg, to protect against jamming). In some scenarios, the UT may be deployed in a corporate environment (eg, placed on a building roof). In this case, the UT may have a relatively large antenna and / or multiple antennas (eg, to provide a relatively high backhaul bandwidth). In some scenarios, the UT may be deployed in a residential environment (eg, placed on a house roof). In this case, the UT may have a smaller (and relatively inexpensive) antenna and provide fixed access (eg, Internet access) for data services. In some scenarios, the UT may be deployed in a marine environment (eg, placed on a cruise ship, cargo ship, etc.). In this case, the UT may have a relatively large antenna and / or multiple antennas (eg, to prevent interference and provide a relatively high bandwidth data service). In some scenarios, the UT can be deployed in a vehicle (eg, carried by a first responder, emergency personnel, etc.). In this case, the UT has a smaller antenna and can be used to provide temporary Internet access to certain areas (eg, where cellular services are out of range). Other scenarios are possible.

  The particular UT configuration may depend on the application for which the UT is used. For example, antenna type, antenna shape, antenna quantity, supported bandwidth, supported transmit power, receiver sensitivity, etc. may depend on the corresponding application. As an example, planar antennas (which are relatively inconspicuous) can be used in aircraft applications.

  In the example of FIG. 4, the UT is shown to include a transceiver, where at least one antenna 410 is provided for receiving forward link communication signals (eg, from satellite 300), where the forward link communication signals are It is forwarded to an analog receiver 414 where it is downconverted, amplified and digitized. A duplexer element 412 is often used to allow the same antenna to provide both transmit and receive functions. Alternatively, the UT transceiver may utilize separate antennas for operation at different transmit and receive frequencies.

  The digital communication signal output by the analog receiver 414 is transferred to at least one digital data receiver 416A and at least one searcher receiver 418. As will be apparent to those skilled in the relevant art, additional digital data receivers (e.g., as represented by digital data receiver 416N) may be desired depending on the acceptable level of transceiver complexity. It can be used to obtain level signal diversity.

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

  The outputs of digital data receivers 416A-416N are coupled to a digital baseband circuit 422 in UT400. Digital baseband circuit 422 includes processing and presentation elements used to transfer information to and from UE 500, for example, as shown in FIG. Referring to FIG. 4, when diversity signal processing is utilized, the digital baseband circuit 422 may include a diversity synthesizer and decoder (not shown). Some of these elements may also operate under control of the control processor 420 or in communication with the control processor 420.

  When voice data or other data is prepared as an output message or communication signal starting from UT400, the digital baseband circuit 422 receives, stores, processes and otherwise prepares the desired data for transmission. Used for. Digital baseband circuit 422 provides this data to transmit modulator 426 operating under the control of control processor 420. The output of transmit modulator 426 is forwarded to a power controller 428 that provides output power control to transmit power amplifier 430 for final transmission of output signals from antenna 410 to a satellite (eg, satellite 300).

  In FIG. 4, the UT transceiver also includes a memory 432 associated with the control processor 420. Memory 432 may include instructions for execution by control processor 420 as well as data for processing by control processor 420. In the example shown in FIG. 4, the memory 432 may include instructions for performing time or frequency adjustments to be applied to the RF signal to be transmitted by the UT 400 via the return service link to the satellite 300.

  In the example shown in FIG. 4, the UT 400 also includes an optional local time, frequency, and / or location reference 434 (e.g., a GPS receiver), which is local time, frequency, and / or Location information can be provided to the control processor 420 for a variety of applications including, for example, time or frequency synchronization for the UT 400.

  Digital data receivers 416A-416N and searcher receiver 418 are configured with signal correlation elements to demodulate and track specific signals. The searcher receiver 418 is used to search for pilot signals or other relatively unchanged pattern strong signals, while the digital data receivers 416A-416N are other signals associated with detected pilot signals. Used to demodulate. However, the digital data receiver 416 may be responsible for tracking the pilot signal after acquisition to properly determine the ratio of signal chip energy to signal noise and formulate pilot signal strength. Thus, the output of these units can be monitored to determine the energy in the pilot signal or other signals, or their frequency. These receivers also utilize a frequency tracking element that can be monitored to provide current frequency and timing information to the control processor 420 for the signal being demodulated.

  The control processor 420 can use such information to appropriately determine how much the received signal is offset from the oscillator frequency when scaled to the same frequency band. This information and other information regarding frequency error and frequency shift may be stored in a storage element or memory element (eg, memory 432) as desired.

  Control processor 420 may also be coupled to UE interface circuit 450 to allow communication between UT 400 and one or more UEs. The UE interface circuit 450 may be configured as desired for communication with various UE configurations, and thus varies depending on the various communication techniques utilized to communicate with various supported UEs. A transceiver and associated components may be included. For example, the UE interface circuit 450 includes one or more antennas, 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 may include other known communication techniques configured to communicate with one or more UEs communicating with the UT 400.

  The control processor 420 performs one or more of processing circuitry 442, memory device 444, or handoff controller 446 that performs handoff information related operations for the UT 400 as taught herein independently or in concert. Multiple may be included. In certain exemplary implementations, the processing circuit 442 is configured (eg, programmed) to perform some or all of these operations. In another exemplary implementation, processing circuit 442 (eg, in the form of a processor) executes code stored in memory device 444 to perform some or all of these operations. In another exemplary implementation, handoff controller 446 is configured (eg, programmed) to perform some or all of these operations. Although illustrated in FIG. 4 as being included in the control processor 420, in other implementations, one or more of the processing circuitry 442, memory device 444, or handoff controller 446 are coupled to the control processor 420. Can be separate subsystems.

  FIG. 5 is a block diagram illustrating an example of UE 500, which may also apply to UE 501 of FIG. UE 500 as shown in FIG. 5 may be, for example, a mobile device, handheld computer, tablet, wearable device, smart watch, or any type of device capable of interacting with a user. In addition, UE 500 may be a network-side device that provides connectivity to various final end-user devices and / or various public or private networks. In the example shown in FIG. 5, UE 500 has a LAN interface 502, one or more antennas 504, wide area network (WAN) transceiver 506, wireless local area network (WLAN) transceiver 508, and satellite positioning system (SPS) reception. Machine 510 may be included. The SPS receiver 510 may be compatible with a global positioning system (GPS), a Global Navigation Satellite System (GLONASS), and / or any other global or regional satellite-based positioning system. In an alternative aspect, UE 500 may include a WLAN transceiver 508, such as a Wi-Fi transceiver with or without a LAN interface 502, a WAN transceiver 506, and / or an SPS receiver 510, for example. In addition, UE 500 may include additional transceivers such as Bluetooth®, ZigBee® and other known technologies, WAN transceiver 506, WLAN transceiver 508, and / or SPS with or without LAN interface 502. A receiver 510 may be included. Accordingly, the elements shown for UE 500 are provided as exemplary configurations only and are not intended to limit the configuration of UEs in accordance with various aspects disclosed herein.

  In the example shown in FIG. 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.

  Memory 516 is connected to processor 512. In one aspect, the memory 516 may include data 518 that may be transmitted to and / or received from the UT 400, as shown in FIG. Referring to FIG. 5, memory 516 may also include stored instructions 520 that are to be executed by processor 512 to perform processing steps for communicating with UT 400, for example. In addition, UE 500 may also include a user interface 522, which includes hardware and hardware for communicating the inputs or outputs of processor 512 to the user, for example, through light, sound, or tactile inputs or outputs. Software can be included. In the example shown in FIG. 5, UE 500 includes a microphone / speaker 524 connected to user interface 522, a keypad 526, and a display 528. Alternatively, the user's tactile input or output may be integrated with the display 528, for example, by using a touch screen display. Again, the elements shown in FIG. 5 are not intended to limit the configuration of UEs disclosed herein, and the elements included in UE 500 are the final usage of the device and the design choices of the system engineer It will be understood that changes based on

  In addition, UE 500 may be a user device, such as, for example, a mobile device or an external network side device that is in communication with, but separate from, UT 400 as shown in FIG. Alternatively, UE 500 and UT 400 may be an integral part of a single physical device.

  In the example shown in FIG. 1, the two UTs 400 and 401 may perform bi-directional communication with the satellite 300 via a return service link and a forward service link in beam coverage. A satellite may communicate with more than two UTs in beam coverage. Accordingly, the return service link from UT 400 and 401 to satellite 300 may be a many-to-one channel. For example, some UTs can be mobile while other UTs can be stationary. In a satellite communication system such as the example shown in FIG. 1, multiple UTs 400 and 401 in beam coverage are time division multiplexed (TDM'ed), frequency division multiplexed (FDM'ed), or both It may be.

UT Handoff At some point, the UT may need to be handed off to another satellite (not shown in FIG. 1). Handoffs can be caused by scheduled or unscheduled events.

  Some examples of handoffs due to scheduled events follow. Inter-beam and inter-satellite handoffs can be caused by satellite motion, UT motion, or satellite beam being turned off (eg, due to geostationary satellite (GEO) constraints). The handoff may also be due to the satellite moving out of range of the GN while the satellite is still in the UT line of sight.

  Some examples of handoffs due to unscheduled events follow. A handoff may be triggered by the satellite being blocked by an obstacle (eg, a tree). Handoffs can also be triggered due to degradation of channel quality (eg, signal quality) due to rain attenuation or other atmospheric conditions.

  In some implementations, at a particular point in time, a particular satellite may be controlled by a particular entity in the GN (eg, network access controller, NAC). Thus, the GN may have several NACs (eg, implemented by the GN controller 250 of FIG. 2), each of which controls a corresponding one of the satellites controlled by the GN. In addition, a given satellite may support multiple beams. Thus, over time, different types of handoffs may occur.

  In handoff between beams, the UT is handed off from one beam of the satellite to another beam of the satellite. For example, the particular beam serving a stationary UT may change over time as the serving satellite moves.

  In a handoff between satellites, the UT is handed off from the current serving satellite (referred to as the source satellite) to another satellite (referred to as the target satellite). For example, the UT may be handed off to the target satellite as the source satellite moves away from the UT and as the target satellite moves toward the UT.

Idle Mode Handoff In a satellite network, a UT in idle mode should face the best satellite and beam to receive a page for the idle UT. Similarly, the GN should page to an idle UT using the same satellite beam. In practice, the selection of the correct satellite and beam can be difficult (e.g., relatively complex), which means that the satellite and beam are known to the GN but not to the idle UT. Because it may be turned off for various reasons. As a result, an idle UT may be able to point to a different satellite than the GN uses to page the idle UT.

  To address this issue, the present disclosure, in some aspects, provides a network induced idle mode handoff procedure that allows an idle UT to reliably receive paging messages transmitted by the GN. About. To receive the page, the idle UT identifies a satellite that will provide coverage for the idle UT at that time and directs the antenna to that satellite. This will cause the idle UT to then camp on the corresponding cell for the beam that the satellite will transmit in, and set the control channel to determine if there is a page for the idle UT. It becomes possible to monitor.

  In some aspects, the idle mode handoff algorithm induced by the network is such that the UT is handed off when the UT is in idle mode repeatedly (e.g., periodically or non-periodically) or as required. Involves providing information to the idle UT that can be used to perform (reselection). This information may be referred to as idle mode information. The UT may maintain this information in an idle mode handoff table.

  The idle mode information can take various forms. In some cases, the idle mode information indicates a sequence of satellites that cover the idle UT for a period of time, so the idle UT then points to the correct satellite (e.g., at a specified time). The page can be received. In some cases, the idle mode information includes a start time for a set of satellites, each specific start time indicating when an idle UT can handoff to the corresponding satellite. Thus, in some aspects, the application relates to network induced idle reselection, where the UT is directed by the network to an appropriate list of satellites for idle mode operation.

  In some scenarios, an idle UT requests idle mode handoff information from the GN. In some scenarios, an idle UT sends a request for idle mode handoff information to the GN when the idle UT has a defined number of valid entries remaining in the idle mode handoff table. obtain. For example, an idle UT may send a request when there is only one entry in the table that has not expired. In some scenarios, an idle UT may send a request for idle mode handoff information to the GN when the idle mode handoff table is about to expire or when it expires. In some scenarios, an idle UT may send a request for idle mode handoff information to the GN based on the time associated with a particular entry (eg, the last entry) in the idle mode handoff table.

  The request may include, for example, the start time of the last entry in the current idle mode handoff table at the UT and the location of the UT. This information allows the GN to determine the next set of satellites that will cover the idle UT and to determine when to send an indication of the next set of satellites to the UT.

  In some scenarios, the GN may send idle mode information to the UT during wireless connection operation. For example, an idle UT may send a request for idle mode handoff information to the GN when the idle UT establishes a wireless connection with the GN. As another example, the GN autonomously sends idle mode handoff information to the idle UT (eg, without a request from the idle UT) when the idle UT establishes a wireless connection with the GN. Can do.

Exemplary Handoff Signaling The disclosure relates in some aspects to signaling for supporting idle mode handoff. FIG. 6 shows a communication system 600 that includes a first device 602 and a second device 604. First device 602 includes a transmitter 608 that can maintain (eg, generate) idle mode handoff information (eg, a table) 606 and transmit idle mode handoff information 610 to second device 604. Second device 604 includes a receiver 612 for receiving idle mode handoff information 610 so that local idle mode handoff information 614 can be maintained. In some aspects, the first device 602 may be an example of the GN 200 or GN 201 of FIG. In addition, the second device 604 may be an example of the UT 400 or UT 401 of FIG.

  In some implementations, the communication system 600 is a satellite communication system. FIG. 7 shows a UT 702 communicating with a GN 704 via a satellite 706 in a non-geostationary satellite communication system 700, such as a LEO satellite communication system for data communication, voice communication, video communication, or other communication. . UT 702, GN 704, and satellite 706 may correspond to, for example, UT 401, GN 200, and satellite 300 in FIG.

  GN 704 includes a network access controller (NAC) 712, each of which communicates with UT 702 and other UTs (not shown) via satellite 706 (or some other satellite not shown). Interface with one or more radio frequency (RF) subsystems 714. The GN 704 also includes a core network control plane (CNCP) 716 and a core network user plane (CNUP) 718, or other similar function, for communicating with another network 720. Network 720 may represent, for example, one or more of a core network (eg, 3G, 4G, 5G, etc.), an intranet, or the Internet.

  At various times, the GN 704 may determine (eg, receive or generate) idle mode handoff information 722. The GN may then broadcast or unicast idle mode handoff information 722 to UT 702 via messages 724 and 726 relayed by satellite 706. The UT 702 thus maintains unique idle mode handoff information 728. The GN 704 may send idle mode handoff information 722 to the UT in response to a request from the UT or autonomously (eg, not responding to the request).

  In an exemplary implementation, the request for the idle mode handoff table may include two fields. The first field contains the start time (eg, absolute GPS time) of the last row entry in the current table. If the UT does not have a current table, the start time can be set to zero. This first field may be 32 bits or some other size. The second field contains the position of the UT corresponding to the last received table (eg, this field can be used only for a moving UT). This field may be 32 bits or some other size. In some implementations, the request also includes an indication of the validity time of the current idle mode handoff table in the UT (e.g. an indication of how long the table is valid) (e.g. in another field). obtain.

  The disclosure relates in some aspects to using unicast signaling based transfer of idle mode handoff information (eg, idle mode handoff table). In some aspects, unicast signaling may provide greater flexibility than idle mode updates based on broadcast information blocks (eg, unicast signaling may be more adaptable for future developments).

  FIG. 8 shows an example signaling call flow 800 for providing handoff information (eg, handoff table) to an idle UT. Signaling call flow 800 includes a wireless message request-response pair, which may be based, for example, on a network induced idle mode handoff algorithm.

  In some aspects, message request-response pairs may be exchanged between the UT 802 and the GN 804 when the UT is wirelessly connected and when security is active (806). That is, the radio request-response message may be used to provide an idle mode handoff table to a wirelessly connected UT, and the table may be provided after security is activated.

  The idle mode handoff table request message 808 may be transmitted after UT location information is transmitted (or may be transmitted simultaneously). For example, the request message 808 may be provided simultaneously with the wireless UT location report message 810.

  In some aspects, the GN may use the UT location information to prepare an idle mode handoff table for the UT. For example, the GN may determine which satellites may be able to serve the UT over a given period based on the satellite ephemeris information and the location of the UT. The GN then sends an idle mode handoff table response message 812 containing this satellite information to the UT, which updates the UT table 814.

  In some implementations, the GN may determine whether to send an idle mode handoff table to the UT based on the validity time of the current idle mode handoff table at the UT. In some cases, the GN may receive this valid time indication from the UT (eg, in an idle mode handoff table request message). In some cases, the GN may track this valid time itself (eg, based on the valid time that the GN calculates for the last table that the GN sent to the UT).

  In some implementations, the GN sends an idle mode handoff table to the UT based on the time (eg, start time) associated with the current idle mode handoff table entry (eg, last entry) in the UT. You can decide whether or not. In some cases, the GN may receive an indication of this time from the UT (eg, in a handoff table request message). In some cases, the GN may track this time itself (eg, by storing the last table that the GN sent to the UT).

  In view of the above, the present disclosure in some aspects relates to transmitting an indication of at least one satellite for UT idle mode operation to the UT. Here, the indication of the at least one satellite may take the form of a satellite table, a satellite list, or some other form. For each satellite of the at least one satellite (eg, in the satellite list), an indication may also be sent to the UT indicating the time at which the UT should handoff to the satellite. An indication of at least one carrier frequency that the next satellite cell (eg, the cell of the next satellite that will serve the UT) will use for transmission may also be sent to the UT.

  In some aspects, the determination of whether to send an indication is 1) the location of the UT, 2) the start time of an entry (e.g., the last entry) in the current idle mode handoff table, 3) the idle mode handoff Based on the number of valid entries in the table, or 4) a combination thereof. In some aspects, the decision to send the indication may be based on the validity time of the last idle mode handoff table provided by the GN to the UT. The above information allows the GN to determine whether the UT is likely to run out of current satellite information. As a result, the GN may send a new table to the UT if the last table sent to the UT is about to run out of valid entries or if the table is about to expire.

Example handoff table
The GN may send idle mode handoff information (eg, autonomously or in response to a request) via an idle mode handoff table. An exemplary idle mode handoff table is shown in Table 1. The table reference time (eg, in seconds) may be, for example, absolute GPS time (eg, 32 bits). This table is updated over time (eg, as the satellite moves and / or as the UT moves). It should be understood that different handoff tables may contain different types of information and / or different entries.

  In an exemplary implementation, the handoff table may include three fields that follow. The first field is for table reference time (eg in seconds): absolute GPS time (eg 32 bits). The second field is for the satellite ID (eg 16 bits). Table 1 shows an example of this field. As shown, the second field may also indicate a supply outage period during which the satellite is not covering the UT (eg, due to EPFD mitigation). The third field is for start times: startTime1, ..., startTimeN (eg 32 bits each). Table 1 also shows an example of this field. These times may be chosen so that the GN can specify a sufficiently long period relative to the reference time during which the table entries are valid.

  The size of the handoff table provided to the UT may depend on whether the UT is stationary or moving. In general, smaller handoff tables may be used for moving UTs, so the size of such handoff tables may depend on the speed at which the UT is moving.

  For UTs that are moving at high speed (eg, UTs on an aircraft), a smaller table can be provided because the table can be quickly invalidated by movement of the UT. Such a table may be valid for several minutes, for example.

  For UTs that are moving slowly (eg, UTs on cruise ships or cargo ships), larger tables may be provided. Such a table may be valid for one hour, for example.

  For stationary UTs, to reduce overhead due to the establishment of a new connection (e.g. as discussed below in option 1) or due to signaling overhead (e.g. as discussed below in option 3) A large table can be provided. Such a table may be valid for several hours (eg, 10 hours), for example.

  The GN can estimate the speed of the UT based on the location report that the GN receives from the UT. Combining this information with the information received in the request message regarding the time that the current table in the UT is valid, the GN can optimize the size of the table that the GN provides to the moving UT. This achieves a good trade-off between the signaling overhead incurred when sending the table and the period during which the table provided for the moving UT can remain valid Get help.

  The outage period can exist for various reasons under various circumstances. For example, one or more satellites may become inactive (e.g. during periods when the UT would otherwise be in their coverage), thereby providing service It may not be possible. As another example, a service constraint (e.g., due to regulatory constraints or country) that the UT cannot receive service from a particular satellite (e.g., the service is always constrained at a certain time or location) Constraints) may prescribe.

  In some aspects, the outage period information may be used by the UT to determine whether to stay in or enter a low power (eg, sleep) mode. For example, a UT in idle mode or entering idle mode may determine that it can sleep from startTime2 to startTime3 based on Table 1.

Triggers for Requesting or Sending Idle Mode Handoff Information Various types of triggers can be used to determine when to request or send idle mode handoff information (eg, an idle mode handoff table). A trigger that can be used to determine when the UT requests idle mode handoff information, or can be used by the GN (or some other type of device) to determine when to send idle mode handoff information Some examples of follow.

  The first request trigger is based on the number of valid entries remaining in the set of idle mode handoff information (eg, idle mode handoff table) held by the UT (or some other suitable device). For example, the UT may send a request for idle mode handoff information based on the number of valid entries remaining in the idle mode handoff table maintained by the UT (eg, 1, 2, etc.). As a specific example, the UT sends a request for idle mode handoff information to the GN if the idle mode handoff table contains only one valid entry (or two valid entries, or three valid entries, etc.) Can do. In this way, the UT can obtain a new idle mode handoff table from the GN before there are no valid (eg, latest) entries from the idle mode handoff table held by the UT. In some aspects, an entry in the table may be considered invalid (eg, not up-to-date) after the time associated with the entry (eg, start time, end time, etc.) has elapsed.

  The second request trigger is based on the timing of entries in the set of idle mode handoff information (eg, idle mode handoff table) held by the UT (or some other suitable device). For example, the UT is based on the timing (e.g., start time, end time, etc.) associated with a particular entry in the idle mode handoff table held by the UT (e.g., last entry, penultimate entry, etc.). A request for idle mode handoff information may be sent. In a particular example, the UT has a difference between the current time and the time (e.g., start time) for a particular entry (e.g., the last entry) in the idle mode handoff tail that is less than a certain amount of time. In some cases, a request for idle mode handoff information may be sent to the GN. In this way, the UT is new from the GN before there are no more recent entries from the idle mode handoff table held by the UT (e.g., before there are no more entries from the table, or before the table is no longer valid). An idle mode handoff table can be obtained.

  The third request trigger is based on a combination of the first request trigger and the second request trigger. For example, the UT may indicate idle mode handoff information if the idle mode handoff table contains only one valid entry, or if the difference between the current time and the time of the last entry is less than the threshold time length. A request for can be sent to the GN. Other combinations may be used in other scenarios.

  In some scenarios, the GN (or some other suitable device) may use the UT table (or some other device) to determine when to send idle mode handoff information (e.g., idle mode handoff table). Table). Such a scenario can occur, for example, when the UT (or some other device) does not send a request for a new table.

  The first transmission trigger is based on how much idle mode handoff information (eg, idle mode handoff table) sent to the UT (or any other suitable device) remains valid. For example, the GN (or some other suitable device) may send idle mode handoff information to the UT based on the remaining validity period of the UT's idle mode handoff table. In a particular example, the GN may send a new idle mode handoff table to the UT if the remaining validity period of the last idle mode handoff table that the GN sent to the UT is less than a threshold length of time. In this way, the GN may provide a new idle mode handoff table to the UT before the retained UT idle mode handoff table becomes invalid.

  Other triggers for transmitting idle mode handoff information may be similar to the first request trigger, the second request trigger, and the third request trigger. For example, the GN determines the time (e.g., start time) for a particular entry (e.g., the last entry) in the UT's idle mode handoff table based on the number of valid entries remaining in the UT's idle mode handoff table. ) Or based on a combination of these triggers may transmit idle mode handoff information.

Example message
The GN (or some other suitable device) may send various types of information to the idle UT (or some other suitable device). In some scenarios, this information may be sent via a broadcast information block (BIB) message. In one exemplary implementation, this information indicates at least one carrier frequency (eg, an absolute radio frequency channel number) that the next cell will use to transmit. This information may be carried by a 16-bit (or other size) parameter called “nextCellTransmitFreq”. As an example, nextCellTransmitFreq may indicate a list of possible frequencies that may follow. As another example, nextCellTransmitFreq may indicate a specific frequency. It should be understood that nextCellTransmitFreq can take other forms. It is assumed that the satellite will transmit using a limited number N (e.g., 8 or some other suitable number) of carrier frequencies on the forward service link (FSL) over a given area. The The set of N carrier frequencies can vary from region to region.

  The UT may perform the following operations to match the satellite beam. When the UT switches from one satellite to another according to the idle mode handoff table, the UT may perform a search over N frequencies and select one frequency to camp on. The UT may use nextCellTransmitFreq information when switching from one beam of the satellite to another beam of the satellite. For example, when the UT is covered by a satellite, the UT may use nextCellTransmitFreq information to determine the next beam that the UT should match.

Exemplary Signaling Some examples of signaling and UT procedures based on the above follow. These examples are called Option 1, Option 2, Option 3, and Option 4.

  In option 1, an idle UT sends a request message to the GN when only one entry remains in the current table of UTs. Here, the UT establishes a wireless connection to the GN and sends a request message. The UT radio layer may trigger the control layer to initiate a service request procedure and establish a radio connection to the GN. Upon receiving the request message, the GN sends a response containing the new handoff table to the UT. When UT receives the response message, it replaces the current table with the new table.

  In option 2, the UT does not send a request message. Instead, the GN maintains, for each UT, information about the validity time of the last table that the GN provided to the UT. Whenever the UT establishes a wireless connection to the network, the GN checks if a new table needs to be provided and sends a new table if necessary. In some cases, the GN may send a new table after the GN receives a radio location report message indicating the location of the UT from the UT.

  In option 3, the UT sends a request message to the GN whenever the UT establishes a wireless connection to the GN. Based on the information provided in the request message, the GN determines whether the table needs to be provided to the UT. For example, a stationary UT need not be provided with a new table if the UT has an entry for a sufficient time in the future. For a moving UT, the GN provides a table to the UT based on the information provided in the request message (eg, as discussed for the table size of the stationary UT and the moving UT) The size of can be optimized. When the UT receives a response message from the GN, the UT may replace the duplicate entry and add a new entry to the current table.

  Option 2 can be used when the UT has uplink (UL) data to send, or when the UT responds to a page, or when a periodic timer (e.g., a 54 minute period) expires. Allows the procedure to piggyback on a wireless connection established by the UT for any reason. Thus, in these scenarios, it may not be necessary to set up an additional connection to send a request or receive an idle mode handoff. In some implementations, the timer may be a paging area update timer. Other types of timers may be used in other implementations.

  Option 4 is a combination of option 1 and option 3. For example, the UT may establish a wireless connection to obtain a new table whenever the UT approaches the end of the current table. In addition, the UT may request a table whenever a wireless connection is established for other reasons. An example of option 4 follows.

  When an idle UT discovers that there is only one entry left in the UT's current table, the UT radio triggers the control layer to initiate a service request procedure and establish a radio connection to the GN To do. The UT then sends a handoff request over the connection, and the GN provides a new table to the UT in response. UT then replaces the current table with a new table.

  As discussed above, stationary UTs and moving UTs may have different constraints. A stationary UT may benefit from a large table (more than 10 hours) to reduce connection overhead. A moving UT may use a smaller table because large movements can invalidate the table. Thus, the amount of handoff information transmitted by the GN may be based on UT movement (eg, speed).

  As discussed above, the UT may send a handoff table request message whenever the UT gets a radio connected to the GN. Upon receipt of this message, the GN determines whether the UT should be provided with a table. A stationary UT need not be provided with a new table if the UT's current table has entries for sufficient time in the future. For moving UTs, GN can provide a smaller size table. When the UT receives the response message, it can add it to the handoff table (eg, replace duplicate entries).

Example Timeline Figure 9 shows an example of an idle UT when the idle UT switches from the first satellite (designated SAT1) to the second satellite (designated SAT2) according to the handoff table. A timeline 900 is shown. This example is for a UT with two parabolic antennas. In an exemplary implementation, the worst case time 902 it takes for the antenna of the UT (eg, antenna 2) to complete rotation and face toward SAT 2 is shown. In an exemplary scenario, such an antenna may take approximately 5 minutes to rotate a 90 degree elevation angle (e.g., the minimum elevation sweep rate at a particular azimuth may be 18 degrees / second). is there).

  At time 904, the antenna of UT (antenna 2) rotates and starts to face SAT2. At time 906, the UT reads the BIB in the current cell and finds the next cell to match. At a paging opportunity (PO) 908, the UT uses another antenna (eg, antenna 1) to monitor the control channel in the subframe and determine whether there is a page for the UT 910. At SAT2 start time 912, the antenna 2 of the UT faces the second satellite SAT2. At time 914, the UT measures the FSL frequency in the next cell to camp on. For example, the UT may measure for 120 milliseconds or some other period. At time 916, the UT reads and processes BIB1. For example, the UT may perform these operations for 85 milliseconds or for some other period. UT participates in the page during PO918. In one exemplary implementation, the page period 920 is 1280 milliseconds.

Additional Handoff Operations Referring to FIG. 10, various aspects of the present disclosure relate to a handoff of a UT 1002 communicating with a GN 1004 via a satellite 1006 in a satellite communication system 1000. In some implementations, the system 1000 can be a non-geostationary satellite communication system, such as a low earth orbit (LEO) satellite communication system for data communication, voice communication, video communication, or other communication. UT1002 is an example of UT400 or UT401 in FIG. GN1004 is an example of GN200 or GN201 in FIG. Satellite 1006 is an example of satellite 300 in FIG.

  In some aspects, GN 1004 and UT 1002 use satellite and cell transition information 1008 to determine when to handoff UT 1002 from one cell to another and / or from one satellite to another. For example, the UT 1002 may send UT information 1010 (eg, capability information, location information, or other information) to the GN 1004 via the first signaling 1012. Based on information 1010, GN 1004 or some other entity generates satellite and cell transition information 1008 and sends information 1008 to UT 1002 via second signaling 1014. Alternatively or additionally, the GN 1004 or some other entity selects a handoff procedure for the UT 1002 based on the information 1010. In some aspects, the handoff of the UT 1002 to a different satellite (new serving satellite) involves the UT 1002 making a satellite signal measurement and sending a measurement message 1016 to the GN 1004. In some aspects, the GN 1004 generates new satellite and cell transition information (eg, modifies the satellite and cell transition table) as a result of receiving the measurement message 1016.

  The UT 1002 may perform other handoff related operations in accordance with the teachings herein. In some aspects, the UT 1002 may receive satellite ephemeris information via the GN 1004 and use the satellite ephemeris information to synchronize to a satellite (eg, satellite 1006). In some aspects, the UT 1002 invokes a radio link failure mode if the UT 1002 loses connection to the satellite and / or cell.

  In some aspects, the handoff design may attempt to meet one or more design objectives. Examples of such purposes include minimizing signaling during handoff, minimizing data outage during handoff, or reducing reliance on UT knowledge about satellite ephemeris data (For example, instead relying on GN's knowledge of satellite position and UT position).

  In the example of FIG. 10, the GN 1004 includes a network access controller (NAC) 1018, each of which is connected via a UT 1002 and other UTs (not shown) and a satellite 1006 (or some other satellite not shown). Interfaces with one or more radio frequency (RF) subsystems 1020 for communication. The GN 1004 also has a core network control plane (CNCP) 1022 and core network user plane (CNUP) 1024, or other similar function (e.g., a control plane for other types of networks and User plane function). Network 1026 may represent, for example, one or more of a core network (eg, 3G, 4G, 5G, etc.), an intranet, or the Internet.

  In some implementations, the GN 1004 determines (eg, receives or generates) satellite and cell transition information 1008. For example, the NAC 1018 is for all UTs under the control of the NAC 1018 based on information received over the network 1026 (e.g., ephemeris information) and information received from the UT (e.g., configuration information and measurement messages). Satellite and cell transition information may be generated. As another example, NAC 1018 may receive satellite and cell transition information for UTs of NAC 1018 via network 1026 (eg, from network entity 1028).

  Other entities in the system may also generate satellite and cell transition information 1008. In some implementations, the controller 1030 of the network entity 1028 generates satellite and cell transition information 1008, and the satellite and cell transition information 1008 to the control component of the system 1000 (e.g., during system startup, and / or Or at other times). For example, network entity 1028 may send satellite and cell transition information 1008 to GN 1004 via network 1026 (eg, core network, intranet, or Internet) or some other data transfer mechanism. For illustration purposes, the network entity 1028 is illustrated as being outside the network 1026. However, network entity 1028 may be part of network 1026.

  Several exemplary aspects of a UT, GN, or satellite that may be used in conjunction with a UT handoff in accordance with the teachings herein will now be described. These aspects, for a given one of these satellite system components, parameters or other information used by the component, parameters assigned to the component, component characteristics (e.g., capability), It may include one or more of signaling used by the component, or operations performed by the component.

Satellite ID
A satellite identifier (ID) is a unique ID of a particular satellite in the satellite system. The satellite ID allows the satellite to be uniquely identified within the satellite system (eg, by UT). The satellite ID may be 16 bits or more to allow large scale satellite deployment. In some implementations, the satellite ID is transmitted over the overhead channel and does not need to be read immediately by the UT. The UT and GN may index the ephemeris information table using the satellite ID to locate the satellite and the projection of the satellite cell to the surface at a given time.

Cell or beam ID
The cell ID is a unique ID of the cell. Similarly, the beam ID is a unique ID of the beam. For convenience, the term cell / beam may be used herein to denote a cell and / or beam. The cell / beam ID allows a cell / beam from a given satellite to be uniquely identified (eg, by UT). In some aspects, the cell / beam ID may be detectable by the UT for a very short period of time (e.g., the cell / beam ID may be a continuous signature used on the pilot of the cell / beam ). Thus, the UT may not need to decode the overhead message to find the cell / beam ID. In one non-limiting example, the cell / beam ID is 2 bits relative to the GN ID (e.g. 2 bits may be sufficient to have a unique GN that the UT can see and the GN ID Can be reused throughout the earth), 8 bits for cells / beams commanded by GN (e.g. GN is about 10 satellites x 16 beams / satellite = 160 beams / It may contain 10 bits, controlling the GN → 8 bits to uniquely identify the cell / beam. In other implementations, a different number of bits may be used. Also, satellite spatial diversity can be considered to reduce the number of bits.

UT capability
The UT may exchange UT capabilities with the GN at connection time or some other time. Some non-limiting examples of UT capabilities follow.

  The UT may be capable of dual cell / beam sensing. Thus, one UT capability parameter (eg, taking a value of YES or NO) may indicate whether the UT is capable of sensing more than one cell / beam. For example, this capability parameter can be detected by the UT sensing and detecting the cell / beam ID of another cell / beam of the same satellite while the UT is actively communicating using that cell / beam of a particular satellite Can indicate whether or not. In some implementations, this capability parameter may be used to indicate whether the UT can support two cells / beams simultaneously. In other implementations, different numbers of cells / beams (eg, 3 or more) may be supported.

  The UT may be capable of dual satellite sensing. Thus, another UT capability parameter (eg, taking a value of YES or NO) may indicate whether the UT is capable of sensing more than one satellite. For example, this capability parameter may indicate whether a UT can sense and detect another satellite's cell / beam ID while it is actively communicating using that satellite's cell / beam. . In some implementations, this capability parameter may be used to indicate whether the UT can support two satellites simultaneously. In other implementations, different numbers of satellites (eg, three or more) may be supported.

  As discussed in more detail below, the GN may use the sensing capabilities of the UT to determine what type of handoff to use for the UT. For example, if the UT can only support a single cell / beam at a time, the handoff may simply be based on satellite and cell transition tables. Conversely, if the UT can support multiple cells / beams / satellite at a certain time, the GN can monitor the measurement messages from the UT during the handoff, so that The measurement message can affect when and / or where it is handed off.

  Another UT capability parameter may indicate inter-cell tuning time and / or inter-beam tuning time for UT (eg, in microseconds (μsec)). For convenience, the term cell / beam tuning time may be used to refer to intercell tuning time and / or interbeam tuning time. This UT capability parameter may indicate the length of time it takes for the UT to stop listening to the cell / beam and start to listen to another cell / beam on the same satellite. Thus, in some aspects, the inter-cell / beam tuning time indicates how long it takes for the UT to tune from one cell / beam to another.

  Another UT capability parameter may indicate an inter-satellite tuning time for UT (eg, in microseconds (μsec)). This UT capability parameter may indicate the length of time it takes for the UT to stop listening to a cell / beam on the current satellite and to start listening to another satellite's cell / beam. Thus, in some aspects, the inter-satellite tuning time indicates how long it takes to tune from one satellite to another.

  In some implementations, the tuning time may be capped. For example, the tuning time may indicate the maximum amount of time expected to take to tune from one cell / beam or satellite to another.

  In some implementations, the tuning time can be expressed according to an equation. A non-limiting example of such a formula is a + b * τ, where a is a constant indicating the minimum length of time for tuning between satellites, and τ is the current satellite and The difference in angle with the target satellite (in degrees), and b is the UT antenna's velocity of motion in milliseconds.

Detuning definition
Signaling can be utilized to allow the UT to detune for inter-satellite sensing and cell / beam sensing. This signaling can be used to define a detuning period for the UT to sense other cells / beams of the same satellite or other satellites.

UT position
A UT location reporting mechanism is utilized for handoff processing and paging so that the GN knows the location of the UT (eg, continuously or periodically). In some implementations, the UT has a reliable Global Positioning System (GPS) positioning.

  For a stationary UT, the UT location reporting mechanism may involve the UT sending a signaling message to the GN reporting the location of the UT (eg, GPS coordinates).

  For a moving UT (eg, a UT in a ship or aircraft), the UT location reporting mechanism may involve sending a signaling message to the GN reporting the UT's speed and direction. This allows the GN to continuously estimate the position of the UT. Even for a moving UT, the direction and speed information may be relatively stable if the UT is carried by (eg attached to) a relatively large container.

  Also, via location related signaling, the UT can be informed of the allowed position deviations before a new location update message is required.

  Some implementations may utilize a threshold of location tolerance. Some implementations may utilize GEO fencing. For example, if the UT crosses the boundary designed for the satellite and / or GN (eg, the UT is some distance away), the UT may be configured to send a location update to the GN.

Ephemeris Transfer and Update Signaling Ephemeris transfer and update signaling messages may be used to transmit satellite ephemeris data to the UT. In some aspects, ephemeris data includes a geographical description of where a given satellite is at a given time. This data may be used by the UT when searching for the next satellite and cell / beam (eg, after the UT detects a radio link failure). For example, in some aspects, the UT may use a given satellite's ephemeris data to determine where to direct the antenna (s) of the UT at a given time. In some aspects, the GN may send a signaling message that includes satellite ephemeris data to all connected UTs (eg, whenever there is an update). In some aspects, the UT may request satellite ephemeris data from the GN (eg, when the UT establishes a connection).

Satellite and Cell Transition Table Each satellite beam can be considered as a separate cell with its own data and control channels and signals. A GN or some other entity may generate a satellite and cell transition table that provides a list of satellites from which the UT may choose to handoff next. The transition table may also precisely define at what time the UT will switch from one cell (eg, corresponding to a beam and / or RF band) of the next satellite to another cell. The transition table may indicate for some satellites the cells (eg, beams and / or bands) to be used for each satellite. The transition table may indicate, for each cell (eg, beam), the cell's frequency (eg, nominal radio frequency or frequency band). The transition table may also indicate the cell ID of each cell (or the beam ID of each beam).

  The GN may define satellite and cell transition tables based on various information. In some aspects, the GN may define the table using the position of the UT (and velocity and direction, if specified). In some aspects, the GN may define a table using satellite positions over time calculated from ephemeris data. In some aspects, the GN may define a table based on information regarding whether some cells / beams and / or satellites are turned off at some time.

Table 2 is an example of a satellite and cell transition table. The entries in this table include satellite ID, beam ID, beam frequency (Freq), start time, and end time. This table may also be referred to as a satellite and beam transition table. TA _beam represents the detuning time from one _beam of the same satellite to another. In this example, UT is between the time a ₁ time b _1, satellite 1, will be tuned to the beam 1 (in a frequency F _11). The UT will then tune to satellite 1, beam 2 (on frequency F ₂₁ ) from time b ₁ + TA _beam to time c ₁ , and so on.

  In some implementations, the table may be sent in a signaling message by the GN to the GN served by the GN at any time before the UT is handed off to the next satellite.

  In one example, the overhead of the satellite and cell transition table message (assuming there are two satellites listed in the table) is: Satellite ID = 16 bits, beam ID = 10 bits, frequency = 4 bits (assuming 16 beam frequencies per satellite), and start and end times = 15 bits.

  The start time and end time may be specified with respect to the frame number. The physical layer may specify that a 10 millisecond (ms) transmission frame be used for the system. Assuming a satellite handoff occurs every 3 minutes, the number of frames that can be transmitted between handoffs is 18,000. The frame number may be re-initialized from 0 after each handoff. Thus, in this example, the number of bits required to specify the frame number is 15 bits.

In the above example, the overall overhead of the message is 1020 bits = 128 bytes (rough). The values of a ₁ , b ₁ ,..., n ₁ and TA _beam are specified.

If up to 1000 active users can be serviced at any time by one beam and the total downlink (DL) throughput of the beam is about 300 Mbps, the overhead is overhead = (128 bytes * NumUsersBeam) / (total bytes delivered by beam over 3 minutes) = (128 bytes * 1000) / (300 * 10 < ⁶ > * 3 * 60) = 19 * 10 < ^-6 > (roughly).

  Table 3 is another example of a satellite and cell transition table. The satellite ID is a unique ID assigned to a satellite in the system. The forward link (FL) band is a positive integer index that identifies the transmission frequency band of the FL. The return link (RL) band is a positive integer index that identifies the RL transmission frequency band.

  The handoff activation time specifies the time at which the UT should stop transmitting and receiving. In some implementations, this time is specified in the source cell in units of system frame numbers (SFN). The SFN may be a sequence number assigned to a physical layer transmission radio frame of 10 ms, for example. The UT stops transmission and reception at the beginning of the SFN. For example, if the handoff activation time is specified to be in SFN 5, the UT stops transmitting or receiving in subframe 0 of SFN 5.

  The UT starts transmission or reception in the target cell at a time obtained by adding the handoff activation time and the detuning time. Two examples of UT parameters for detuning time are intercell detuning time and intersatellite detuning time. These parameters may be included in the UT capability information.

Inter-Satellite Handoff FIGS. 11 and 12 show examples of intersatellite handoff. In these examples, the GN includes a source NAC that controls a first satellite and a target NAC that controls a second satellite. In each case, the UT is first connected to the source satellite (and hence the source NAC) and then handed off to the target satellite (and thus the target NAC). In other implementations, different numbers of NACs and satellites may be supported. Also, in some implementations, a common (eg, the same) entity may support multiple satellites.

  FIG. 11 is an example in which the UT 1102 does not transmit a measurement message. For example, UT 1102 may not support sensing of multiple cells / beams and / or satellites, or UT 1102 may determine that a measurement message need not be sent to GN 1104. In this case, UT1102 and GN1104 will determine when to transition to the next cell / beam and / or satellite and where (for example, to which cell / beam, to which frequency, to which satellite) Depends on existing satellite and cell transition table. UT1102 is an example of UT400 or UT401 in FIG. GN1104 is an example of GN200 or GN201 in FIG.

  The source NAC 1106 sends control signaling 1108 to the UT 1102. This control signaling 1108 may include, for example, measurement information and detuning control information (eg, detuning definition). In addition, packet data 1110 is exchanged between the UT 1102 and the source NAC 1106. Source NAC 1106 is an example of NAC 1012 in FIG.

  At some point, a handoff is triggered (1112). For example, the current time may correspond to the time for a transition from one satellite to the next satellite indicated by the satellite and cell transition table.

  Other handoff triggers may also be utilized. For example, GN 1104 (eg, source NAC 1106) may autonomously determine that UT 1102 needs to be handed off. Such triggers can be, for example, that the current serving satellite is moving out of range of UT1102, that the satellite is moving out of range of GN1104 even though it can be in range of UT1102, or This may be due to the serving cell / beam being blacked out due to GEO requirements.

  If it is possible to sense another cell / beam and / or satellite while the UT1102 is connected to the first satellite, the UT1102 will use the default satellite and cell / beam signal strength for handoff. You can look for it. The UT 1102 may be assumed to have this satellite's location information to do so. This position information can be obtained from satellite ephemeris data processed by the UT 1102. If the signal strength is satisfactory, the UT 1102 only waits for the source NAC 1106 to initiate the inter-satellite handoff process.

  Thus, in the example of FIG. 11, both the UT 1102 and the source NAC 1106 follow the table and initiate a handoff to a new serving satellite. For this purpose, the source NAC 1106 performs a handoff process 1114. For example, source NAC 1106 may communicate with target NAC 1116 to initiate a handoff. In some aspects, this may involve synchronizing (1118) a queue (eg, a packet traffic queue) between NACs 1106 and 1116. Also, since the handoff time is known to be early, the user queue can be transferred early. The target NAC 1116 is an example of the NAC 1012 in FIG.

  Source NAC 1106 then sends handoff signaling 1120 to UT 1102. In some aspects, this handoff signaling 1120 may include information that enables the UT 1102 to communicate with the target NAC 1116. In some aspects, this handoff signaling 1120 may include a new satellite and cell transition table (eg, received by the source NAC 1106 from the target NAC 1116).

  The UT 1102 then disconnects from the first satellite (1122) and synchronizes to the second satellite. For this purpose, the UT 1102 may send synchronization signaling 1124 for the second satellite to the target NAC 1116. In some aspects, this may involve the UT 1102 performing a random access procedure at the second satellite.

  UT 1102 and target NAC 1116 may then exchange connection signaling 1126 and 1128. In some aspects, this may involve target NAC 1116 sending ephemeris information to UT 1102 and requesting a channel quality indicator from UT 1102. In some aspects, the UT 1102 may synchronize with the second satellite using ephemeris information.

  Various entities may also perform various background operations to ensure that packet forwarding is done properly and any necessary cleanup (eg, cache cleanup) is performed.

  FIG. 12 is an example in which the UT 1202 transmits a measurement message. For example, the measurement message needs to be sent to the GN 1204 because the measured channel condition (eg, signal strength) from the serving or target satellite is not acceptable (eg, the signal strength is too low) May be determined. In this case, the GN 1204 may generate a new satellite and cell transition table based on the measurement message. The UT1202 and GN1204 are then new to determine when to transition to the next cell / beam and / or satellite and where (e.g., to which cell / beam, to which frequency, to which satellite) Use satellite and cell transition tables. UT1202 is an example of UT400 or UT401 in FIG. GN1204 is an example of GN200 or GN201 in FIG.

  As in the case of FIG. 11, the source NAC 1206 sends control signaling 1208 to the UT 1202. This control signaling 1208 may include, for example, measurement information and detuning control information (eg, detuning definition). In addition, packet data 1210 is exchanged between the UT 1202 and the source NAC 1206. Source NAC 1206 is an example of NAC 1012 in FIG.

  At some point, a handoff is triggered (1212). In some cases, the current time corresponding to the time for a transition from one satellite to the next satellite as indicated by the satellite and cell transition table triggers the handoff. In some cases, a measurement message sent by the UT 1202 that indicates that a neighboring satellite is significantly stronger (eg, associated with a stronger received signal strength) than the current serving satellite may trigger a handoff.

  Other handoff triggers may also be utilized. For example, GN 1204 (eg, source NAC 1206) may autonomously determine that UT 1202 needs to be handed off. Such triggers can be, for example, that the current serving satellite is moving out of range of UT1202, that the satellite is moving out of range of GN1204 even though it can be in range of UT1202, or This may be due to the serving cell / beam being blacked out due to GEO requirements.

  In the example of FIG. 12, the UT 1202 can sense another cell / beam and / or satellite while connected to the first satellite. Accordingly, the UT 1202 may perform channel quality measurements (eg, satellite signal strength measurements). For example, the UT 1202 may measure signal strength from the current serving satellite (first satellite) and the target satellite (second satellite) (1214).

  The UT 1202 then performs a measurement process (1216), for example, to determine if any channel quality is inappropriate (eg, signal strength is too low). If any channel quality is inappropriate, the UT 1202 may choose to send a measurement message 1218 to the source NAC 1206. This measurement message 1218 may include, for example, the result of the measurement (e.g., signal strength in dB), an indication that the handoff time needs to be advanced (e.g., the signal from the source satellite is currently too weak), (e.g., It may include an indication that the handoff time needs to be delayed (since the signal from the target satellite is currently too weak) or some other indication.

  Thus, similar to FIG. 11, UT 1202 may look for default satellite and cell / beam signal strengths for handoff. Again, it can be assumed that the UT 1202 has position information for this satellite (eg, obtained from satellite ephemeris data that the UT 1202 processes) to do so. If the signal strength is not satisfactory, the UT 1202 may send a measurement message 1218 to the source NAC 1206 indicating a different satellite than the default satellite to trigger the handoff process early or delay it.

  Thus, the source NAC 1206 may make a determination to handoff the UT 1202 to the target satellite and target NAC 1220 based on the satellite and cell transition table and any measurement message 1218 that the source NAC 1206 receives from the UT 1202. Accordingly, as shown in FIG. 12, the source NAC 1206 performs some handoff processing 1222. For example, source NAC 1206 should determine whether handoff time needs to be advanced (early handoff) or delayed (delayed handoff) based on measurement message 1218, or some other satellite should be selected as the target. It can be judged whether there is. In addition, source NAC 1206 may communicate with target NAC 1220 to initiate a handoff. In some aspects, this may involve synchronizing a queue 1224 (eg, a packet traffic queue) between NACs 1206 and 1220. The target NAC 1220 is an example of the NAC 1012 in FIG.

  Source NAC 1206 then sends handoff signaling 1226 to UT 1202. In some aspects, this handoff signaling 1226 may include information that enables the UT 1202 to communicate with the target NAC 1220. In some aspects, this handoff signaling 1226 may include a new satellite and cell transition table (eg, received by the source NAC 1206 from the target NAC 1220).

  The UT 1202 then disconnects from the first satellite (1228) and synchronizes to the second satellite. For this purpose, the UT 1202 may send synchronization signaling 1230 for the second satellite to the target NAC 1220.

  UT 1202 and target NAC 1220 may then exchange connection signaling 1232 and 1234. In some aspects, this may involve the target NAC 1220 sending ephemeris information to the UT 1202 and requesting a channel quality indicator from the UT 1202. Again, various entities may perform various background operations to ensure that packet transfers are properly performed and any necessary cleanup (eg, cache cleanup) is performed.

  With normal intersatellite handoff, the hybrid automatic repeat request (HARQ) process can be terminated. However, since the source NAC can know exactly when the handoff occurs, the source NAC can ensure that the forward link data buffer is empty. Also, since the handoff time is known, the data flow gap can be minimized.

Inter-beam handoff Cell / inter-beam handoff is performed synchronously by the GN and UT according to the timeline specified in the satellite and cell transition tables. Using the detuning period or dual receive capability, the UT detects the presence of the next cell / beam specified in the satellite and cell transition table. If the UT succeeds in detecting the next cell / beam, a normal cell / beam handoff is performed without any signaling between the UT and the GN.

  With normal cell / beam handoff, the forward link HARQ process can be carried over from one cell / beam to the next. In addition, when handing off from one cell / beam to the next cell / beam, the reverse allocation can be canceled. For example, the UT may instead send a new request message to send reverse link data.

Exception scenario
If the UT loses the current serving cell / beam before expiration of the specified time in the satellite and cell transition table, the UT enters radio link failure (RLF) mode. In RLF mode, the UT may attempt to find an alternative cell / beam or satellite (eg, based on ephemeris information in the UT). For example, the UT may attempt to connect to the next satellite to serve the UT. If the UT succeeds in establishing another connection, the UT can send a signaling message to the GN to continue communication where the UT left before the RLF.

  While being served by one cell / beam, the UT may not detect the next cell / beam specified in the satellite and cell transition table, but may detect another cell / beam. This can occur, for example, in a fast moving UT (eg, a UT attached to an aircraft). In this case, the UT may send a measurement message to initiate another handoff procedure. In addition, the UT may also send a location update if the UT has moved since the last time the location update was sent. In response, the GN may send an updated satellite and cell transition table. In this case, UT follows the updated table. Alternatively, the GN may initiate a completely new handoff process.

Exemplary Connected Mode Handoff Details Referring now to FIGS. 13-23, various aspects of wireless connected mode handoff in accordance with the teachings herein will be described in more detail. In the following, examples of call flows for various connection mode handoff operations will be described. In addition, the following details describe some procedures that can be used to improve handoff performance. In various aspects, these procedures define a handoff measurement, determine when to trigger the measurement, determine when to handoff the UT, or UT to obtain return link synchronization after the handoff. Can be used to determine whether to trigger. For purposes of explanation, these details are discussed in the context of NAC with two components, BxP and AxP, for controlling the satellite and / or for communicating with the satellite.

  FIG. 13 shows an exemplary deployment of BxP and AxP components in a satellite system. At a given point in time, UT 1306 communicates with one of AxP 1308 via satellite 1310 and one of BxP 1312, where each BxP 1312 includes or is associated with a satellite RF subsystem 1314.

  BxP refers to the combination of BCP and BTP (hence the acronym BxP). In some aspects, BxP may include a wireless network component for controlling the satellite. For example, a BxP may include for a given cell / beam of a satellite a corresponding set of digital circuits that serve that cell / beam. Thus, in some aspects, BxP corresponds to a particular antenna. Also, in some aspects, a given BxP may be associated with a particular band for a given cell / beam of satellites.

  AxP refers to the combination of ACP and ATP (hence the acronym AxP). In some aspects, AxP corresponds to an anchor point. In some aspects, anchor points may be associated with specific areas (eg, administrative areas, borders, etc.). A given AxP may serve one or more satellites. Also, a given satellite can serve one or more AxPs.

  In the above situation, a UT in connected mode may experience two types of handoff, BxP handoff or AxP handoff. For example, as satellites move in non-GSO satellite systems, the cells / beams used to service a given UT (and therefore the circuits and antennas associated with those cells / beams) change over time. To do. Thus, in some aspects, a BxP handoff may correspond to a handoff to a different cell / beam (or antenna, etc.). As another example, rain attenuation at a particular cell / beam operating on the first band may force switching to a different band for that cell / beam. Thus, in some aspects, a BxP handoff may correspond to a handoff to a different band for a given cell / beam. AxP handoffs correspond to handoffs to different anchor points. For example, the UT may move to a different administrative area and may be forced to change the serving AxP. A BxP handoff may or may not be associated with an AxP handoff.

  In some aspects, the present disclosure below addresses satellite indication errors that may occur in a satellite communication system. These errors can arise from various causes in the system.

  The graph 1400 of FIG. 14 shows the respective expected gain contours 1402 and 1404 from the first and second predicted beams, which are different satellite beams. In some aspects, these beam gain contours may be used to determine when to hand off the UT from one beam to the next. For example, the UT may be handed over when the beam gain from the first expected beam (source beam) currently serving the UT is below the beam gain of the second expected beam (candidate target beam).

  For the first expected beam, FIG. 14 shows the actual beam gain contour 1406 that the UT can see, due to satellite pointing errors. As shown in FIG. 14, the gain contour shift 1408 due to satellite pointing error shifts the intersection of the gain contours between the two beam contours from the first intersection 1410 to the second intersection 1412. Thus, at the expected (ideal) handoff time 1414, the gain from the first beam is lower (by the amount shown) than the expected gain 1416, thereby adversely affecting handoff performance. As a result, the signal quality at the UT may be lower than desired just before handoff. To address this issue, the ideal handoff time can be shifted by Δ (to be earlier in time in this example) based on the beam contour shift 1408 due to satellite pointing errors. Thus, a handoff occurs at a new handoff time 1418. As shown in FIG. 14, the gain 1420 at the new handoff time 1418 may be a Δ gain 1422 lower than the expected gain 1416 associated with the expected first beam.

  For this purpose, the UT may make satellite signal measurements (eg, between satellites and within satellites) and send this information to the GN. Based on these signals, the GN may modify the handoff time for the UT. Thus, the GN may send updated handoff information to the UT (eg, via a satellite and cell transition table or a subset of the satellite and cell transition table) to account for satellite indication errors.

  In some aspects, a random access procedure may be used in situations where the UT has not yet achieved synchronization with the satellite during handoff. For example, a random access procedure based on UT measurements of satellite signals may allow the UT to achieve return link synchronization.

BxP Handoff A logical BxP can be uniquely identified by four tuples including satellite access network (SAN), GN antenna, satellite beam, and forward service link (FSL) frequency. Refers to the antenna. A BxP handoff occurs for a UT when the BxP 4 tuple of the connection of the UT in the wireless connection mode changes.

  Table 4 lists examples of these four types of BxP handoffs and the changes (highlighted in bold) associated with the BxP 4 tuples for each type of BxP handoff. In a feeder link switching handoff, only BxP changes, not the entire SAN.

  A BxP handoff occurs at either a handoff time based on a priori information labeled THO_a_priori or a new handoff time recalculated using a UT measurement report labeled THO_recalc (e.g. 14) THO_recalc = THO_a_priori ± Δ.

  If the satellite antenna indication error is well known a priori, the BxP handoff shall be initiated by the UT based solely on the UT's satellite handoff table (eg, satellite and cell transition table). Otherwise, a BxP handoff may require a UT measurement of the target cell and subsequent measurement reports by the UT to the source AxP, based on the source AxP updating the UT's satellite and cell transition table. .

BxP Handoff-Feeder Link Switching Referring again to FIG. 13, the first configuration 1302 and the second configuration 1304 illustrate a feeder link switching BxP handoff. Each satellite has a dual feeder link connection to two GNs, but only one feeder link connection is active at any given time. The dual feeder link connection allows for instantaneous switching of the active feeder link connection in the satellite. Feeder link switching appears as an idempotent handoff where the UT hands over to the same satellite, the same cell, and the same frequency. However, feeder link switching BxP handoffs can also be made to occur at the same time as cell handoffs for several UTs, in which case the target cell is different from the source cell.

  The call flow for feeder link switching BxP handoff is the same as that shown in FIGS. 15 and 17 discussed below. The call flow of FIG. 15 is applicable when the UT does not need to perform a random access procedure to achieve RL synchronization after feeder link switching occurs. The call flow of FIG. 17 is applicable when the UT needs to perform a random access procedure to achieve RL synchronization after feeder link switching occurs.

BxP Handoff-Non-Random Access FIG. 15 shows the call flow for a non-random access based BxP handoff without UT measurements and measurement reports. A typical use case is an in-satellite BxP handoff. The call flow is between the UT 1502, the source BxP 1504, the target BxP 1506, the source AxP 1508, and the GN 1510.

  A description of the steps in the call flow for non-random access based BxP handoff without UT measurements and measurement reports is given below. The initial packet data flow is represented by lines 1512, 1514, and 1516.

  At point 1518, the source AxP 1508 preconfigures the target BxP 1506 for handoff prior to the handoff activation time (eg, before THO_a_priori) (eg, 1 second before). In step 1A, the source AxP 1508 sends a radio connection reconfiguration message to the UT 1502. In step 1B, the message is sent to the UT 1502 well before the handoff activation time so that the UT 1502 has a suitable time to receive the message. This message may include satellite handoff information, such as a transition table row (eg, indicating handoff activation time) and other parameters. The UT1502 starts timer T-4. When T-4 expires (eg, a handoff failure occurs), UT 1502 performs a wireless connection re-establishment procedure.

  In steps 2A and 2B, based on the single row of the satellite and cell transition table included in the radio connection reconfiguration message in step 1, both UT1502 and source AxP1508 are simultaneously in handoff activation time (e.g. in THO_a_priori ) Prepare for a BxP handoff. Thus, UT 1502 prepares to handoff from source BxP 1504 to target BxP 1506, and source AxP 1508 prepares to hand off UT 1502 from source BxP 1504 to target BxP 1506.

  In step 3, the UT 1502 resets the medium access control (MAC) state. The UT 1502 then obtains a new cell (eg, FL synchronization).

  In step 4, after handoff activation + inter-cell detuning time, the target BxP 1506 sends an RL grant + channel quality indicator (CQI) request to the UT 1502. The RL grant is addressed to the UT identifier (UT-ID) assigned to the UT 1502 by the source AxP 1508 in the radio connection reconfiguration message (see step 1).

  In step 5, upon receiving an RL grant from target BxP 1506, UT 1502 stops timer T-4 (e.g., a successful handoff) and retransmits CQI and reconnects for transmission to source AxP1508 (step 5B). A configuration completion message is transmitted to the target BxP 1506 (step 5A). The wireless connection reconfiguration complete message does not include an information element (IE) and is integrity protected and encrypted using an old key (eg, Kint and Kenc, respectively). The final packet data flow is represented by lines 1520, 1522, and 1524.

  FIG. 16 shows a non-random access based BxP handoff call flow with UT measurements and measurement reports. A typical use case is an in-satellite BxP handoff. The call flow is between UT1602, source BxP1604, target BxP1606, source AxP1608, and GN1610.

  A description of the steps in the call flow for non-random access based BxP handoff with UT measurements and measurement reports follows. The initial packet data flow is represented by lines 1612, 1614, and 1616.

  A radio connection reconfiguration message sent to the UT 1602 while the UT 1602 is serviced by a given source cell may indicate to the UT 1602 when to make a measurement for the next target cell. Accordingly, at point 1617, while in the previous cell, source AxP 1608 may configure UT 1602 with measurement gap information (eg, a gap pattern) corresponding to the measurement time. The source AxP1608 may transmit this information because the satellite indication error may require that satellite handoff be performed at the ideal handoff time ± Δ, thereby compromising measurement by UT1602. is there. In steps 1A and 1B, source AxP 1608 sends a radio connection reconfiguration message to UT1602. This message includes measurement gap configuration information and measurement activation / deactivation time (in addition to handoff activation time and other IEs described herein). In step 3, the UT 1602 measures the signal strength of the target cell according to the measurement gap configuration information received from the source AxP 1608. The packet data flow continues as represented by lines 1618, 1620, and 1622.

  In steps 4A and 4B, the UT 1602 sends a measurement report indicating the signal strength (eg, RSRP) of both the source and target cells to the source AxP 1608 using the event-based report of signal strength. Source AxP 1608 configures UT 1602 to use event 1 (source cell goes better than threshold) as a reference for triggering a measurement report. The source AxP 1608 sets the threshold sufficiently low so that the signal strength of the source cell is always greater than the threshold, thereby triggering the UT 1602 to send a measurement report to the source AxP 1608. Similarly, source AxP 1608 configures UT 1602 to use event 4 (target cell goes better than threshold) as a reference for triggering a measurement report. The source AxP 1608 sets the threshold sufficiently low so that the signal strength of the target cell is always greater than the threshold, thereby triggering the UT 1602 to send a measurement report to the source AxP 1608. Other reporting criteria can also be used.

  In step 5, based on the UT measurement report (see step 4), the source AxP1608 calculates a new handoff activation time (e.g. THO_recalc) and before the new handoff activation time (e.g. before THO_recalc) Pre-configure target BxP1606 for handoff. For example, based on satellite ephemeris information, beam patterns, and UT measurement reports, source AxP 1608 may prepare a BxP handoff to occur at an ideal handoff time ± Δ. In steps 6A and 6B, source AxP 1608 sends a radio connection reconfiguration message to UT1602. The contents of the message, including the new handoff activation time, are described herein. Optionally, the message may also include measurement gap configuration information and measurement activation / deactivation time. The message is sent to the UT 1602 well before the new handoff activation time so that the UT 1602 has a suitable time to receive the message. UT1602 starts timer T-4. When T-4 expires (eg, a handoff failure occurs), UT 1602 performs a radio connection re-establishment procedure. Also, if the source AxP 1608 does not receive a measurement report from the UT 1602 in a timely manner, the source AxP 1608 uses the old handoff activation time (eg, THO_a_priori) when configuring both the target BxP 1606 and the UT 1602 for handoff.

  Based on a single row of the satellite and cell transition table included in the radio connection reconfiguration message in step 6, both UT1602 and source AxP1608 simultaneously prepare for a BxP handoff at a new handoff activation time (eg, in THO_recalc) To do.

  In step 7, the UT 1602 resets the MAC state. The UT 1602 obtains a new cell (eg, FL synchronization).

  In step 8A, after handoff activation + inter-cell detuning time, the target BxP 1606 sends an RL grant + CQI request to the UT1602. The RL grant is addressed to the UT-ID assigned to the UT 1602 by the source AxP 1608 in the radio connection reconfiguration message (see step 3).

  Upon receiving the RL grant from the target BxP 1606, the UT1602 stops timer T-4 (e.g., the handoff was successful), sends a CQI report (step 8A) and a radio connection reconfiguration complete message to the target BxP1606 / source AxP1608 ( Steps 9A and 9B). The wireless connection reconfiguration complete message does not include IE and is integrity protected and encrypted using old keys (eg, Kint and Kenc, respectively). The final packet data flow is represented by lines 1624, 1626, and 1628.

BxP Handoff-Random Access FIG. 17 shows a call flow for a random access based BxP handoff without UT measurements and measurement reports. A typical use case is a BxP handoff between satellites. The call flow is between UT1702, source BxP1704, target BxP1706, source AxP1708, and GN1710.

  A description of the steps in the call flow for random access based BxP handoff without UT measurements and measurement reports follows. The initial packet data flow is represented by lines 1712, 1714, and 1716.

  In steps 1A and 1B, the source AxP 1708 pre-configures the target BxP 1706 for handoff before the handoff activation time (eg, before THO_a_priori). The source AxP 1708 transmits a wireless connection reconfiguration message to the UT 1702. The content of the message is described herein. The message is sent to the UT 1702 well before the handoff activation time so that the UT 1702 has a suitable time to receive the message. The UT1702 starts timer T-4. If T-4 expires (eg, a handoff failure occurs), UT 1702 performs a radio connection re-establishment procedure.

  In step 2, based on the single row of the satellite and cell transition table included in the radio connection reconfiguration message in step 1, both UT1702 and source AxP1708 simultaneously at the handoff activation time (e.g., at THO_a_priori) Prepare for handoff. These operations may be similar to the corresponding operations discussed above in connection with FIG.

  In step 3, the UT 1702 resets the MAC state. The UT 1702 obtains a new cell (eg, FL synchronization). As represented by brackets 1718, if step 1 does not include an RA procedure command, steps 4-7 are not required.

  After handoff activation + intersatellite detuning time, the target BxP1706 uses an FL Control Channel (FLCC) command that includes a dedicated preamble signature to trigger the UT1702 to perform a non-contention based random access procedure. Send to UT1702. This allows the UT 1702 to later achieve RL synchronization.

  In step 4, the UT 1702 sends a non-contention based random access preamble to the target BxP 1706 on random access. Upon receiving a non-contention based random access preamble from UT 1702, target BxP 1706 verifies the received signature sequence.

  In step 5, the target BxP 1706 sends a random access response addressed to the appropriate group of UTs (eg, RA-RNTI) to the UT 1702. The random access response includes a paging area (PA), an RL grant (including CQI request), and a temporary UT-ID.

  If a dedicated preamble signature is used, the RL grant may include a CQI request. In this case, the process may skip from point 1720 to step 8B. Otherwise, the operation of block 1722 including steps 6 and 7 and the operation of step 8A may be performed.

  Upon receiving an RL grant + CQI request from target BxP 1706 (eg, in step 8A), UT 1702 stops timer T-4 (eg, successful handoff) and sends a CQI report (step 8B) to target BxP 1706. If a dedicated preamble signature is used, the UT 1702 also sends a radio connection reconfiguration complete message to the target BxP 1706 (step 9A) for transfer to the source AxP 1708 (step 9B). The wireless connection reconfiguration complete message does not include IE and is integrity protected and encrypted using old keys (eg, Kint and Kenc, respectively). The final packet data flow is represented by lines 1724, 1726, and 1728.

  18 and 19 show the call flow for random access based BxP handoff with UT measurements and measurement reports. A typical use case is a BxP handoff between satellites. The call flow is between UT 1802, source BxP 1804, target BxP 1806, source AxP 1808, and GN 1810.

  A description of the steps in random access based BxP handoff with UT measurements and measurement reports follows. The initial packet data flow is represented by lines 1812, 1814, and 1816.

  Referring first to FIG. 18, while in the previous cell, the UT 1802 is responsible for measuring gap configuration information and measurement activation / deactivation (in addition to the handoff activation time and other IEs described herein). Configured by source AxP1808 in a radio connection reconfiguration message with activation time. In step 1, the UT 1802 measures the signal strength of the target cell according to the measurement gap configuration information received from the source AxP 1808. The packet data flow continues as represented by lines 1818, 1820, and 1822.

  In step 2, the UT 1802 sends a measurement report indicating the signal strength (eg, RSRP) of both the source cell and the target cell to the source AxP 1808 using the event-based report of signal strength. Source AxP 1808 configures UT 1802 to use event 1 (source cell goes better than threshold) as a basis for triggering a measurement report. The source AxP 1808 sets the threshold sufficiently low so that the signal strength of the source cell is always greater than the threshold, thereby triggering the UT 1802 to send a measurement report to the source AxP 1808. Similarly, source AxP 1808 configures UT 1802 to use event 4 (target cell goes better than threshold) as a reference for triggering a measurement report. The source AxP 1808 sets the threshold sufficiently low so that the signal strength of the target cell is always greater than the threshold, thereby triggering the UT 1802 to send a measurement report to the source AxP 1808. Other reporting criteria can also be used.

  Based on the UT measurement report (see step 2), the source AxP1808 calculates a new handoff activation time (e.g. THO_recalc) and before the new handoff activation time (e.g. before THO_recalc) Pre-configure target BxP1806.

  The operations in steps 3 to 11 correspond to steps 1 to 9 in FIG. These operations are therefore briefly discussed. In step 3, the source AxP 1808 sends a radio connection reconfiguration message to the UT 1802. The content of the message, including handoff activation time, is described herein. Optionally, the message may also include measurement gap configuration information and measurement activation / deactivation time. The message is sent to the UT 1802 well before the handoff activation time so that the UT 1802 has a suitable time to receive the message. The UT1802 starts timer T-4. When T-4 expires (eg, a handoff failure occurs), UT 1802 performs a radio connection re-establishment procedure. Also, if the source AxP 1808 does not receive measurement reports from the UT 1802 in a timely manner, the source AxP 1808 will use the old handoff activation time (eg, THO_a_priori) when configuring both the target BxP 1806 and the UT 1802 for handoff.

  In step 4, based on the single row of the satellite and cell transition table included in the radio connection reconfiguration message in step 3, both UT1802 and source AxP1808 are simultaneously at the new handoff activation time (eg, in THO_recalc) Prepare for a BxP handoff.

  In step 5, the UT 1802 resets the MAC state. The UT 1802 obtains a new cell (eg, FL synchronization).

  Referring to FIG. 19, after handoff activation + inter-cell detuning time, target BxP1806 is a FLCC instruction that includes a dedicated preamble signature to trigger UT1802 to perform a non-contention based random access procedure. Is sent to UT1802. This allows the UT 1802 to later achieve RL synchronization.

  In step 6, the UT 1802 sends a non-contention based random access preamble to the target BxP 1806 on random access. Upon receiving a non-contention based random access preamble from UT 1802, target BxP 1806 verifies the received signature sequence.

  In step 7, the target BxP 1806 sends a random access response addressed to the appropriate RA-RNTI to the UT 1802. The random access response includes a paging area, RL grant (including CQI request), and temporary UT-ID.

  Upon receiving an RL grant + CQI request from target BxP1806 (step 10A), UT1802 stops timer T-4 (e.g., a successful handoff), sends a CQI report to target BxP1806 (step 10B), and re-establishes the radio connection. A configuration completion message is transmitted to the target BxP1806 / source AxP1808 (step 11). The wireless connection reconfiguration complete message does not include IE and is integrity protected and encrypted using old keys (eg, Kint and Kenc, respectively). The final packet data flow is represented by lines 1824, 1826, and 1828.

BxP Handoff-Failover With GN antenna failover for intra GN, the antenna assembly serving the satellite fails. In this case, one of two scenarios is possible. In the first scenario, the UT is connected and data managed by the GN as part of normal operation (e.g. scheduling of FL and RL resources for UT by GN, HARQ retransmission and ARQ retransmission). Experience short interruptions in service. In the second scenario, the UT experiences a loss of FL synchronization or there is a significant disruption in connection and data services resulting in radio link failure (RLF).

AxP handoff
Inter-AxP handoff may be performed for load leveling purposes or for non-stationary UTs that require inter-AxP handoff due to UT position changes that result in crossing administrative domain boundaries. The AxP handoff procedure comprises three distinct phases: AxP handoff preparation, AxP handoff execution, and AxP handoff completion.

  The following procedure may be used for AxP handoff preparation.

  For radio controlled (RC) acknowledged mobile (AM) data bearers, where direct data transfer is applied, per RL-AM data bearer for both forward and reverse link data transfer (In one direction from the source AxP to the target AxP). Conversely, if indirect transfer of data is applied, the tunnel will be per RL-AM data bearer (from GN via source GN to target AxP for both forward link and reverse link data transfer). Can be established in one direction).

  For RC unacknowledged mobile (UM) data bearers, if direct transfer of data is applied, the tunnel will be per RL-UM data bearer (from source AxP) for forward link data transfer only. Can be established in one direction to the target AxP). Reverse link data is not transferred from the source AxP to the target AxP, but is instead sent to the GN by the source AxP. Conversely, if indirect transfer of data is applied, a tunnel can be established per RL-UM data bearer (one direction from source AxP to target AxP) for forward link data transfer only . Reverse link data is not transferred from the source AxP to the target AxP, but is instead sent to the GN by the source AxP.

  The following procedure may be used for performing an AxP handoff.

  In the RL-AM data bearer, the data transferred on the reverse link includes a sequence number (SN). The forward link forwarded data may include SN, or may not be included if the forward link data is received from the GN without being assigned SN by the source AxP. The source AxP transmits both the forward link SN and the reverse link SN and frame number (FN) information to the target AxP. The MAC state and RL state are reset.

  For RL-UM data bearers, forward link forwarded data may include SN, or if forward link data is received from GN without being assigned SN by source AxP, May not include. If the forward link forwarded data contains SN, the target AxP should first send this data to the UT (after resetting both SN and FN). The state is reset (eg, forward link and reverse link SN and FN are reset). The MAC state and RL state are reset.

  The following procedure may be used for handoff completion.

  For RL-AM data bearers, the UT may send a list of missing / received forward link protocol data units (PDUs) to the target AxP, which is missing / received reverse A list of directional link PDUs can be sent to the UT. For both RL-AM and RL-UM data bearers, the forward link tunnel for each data bearer is switched from source AxP to target AxP, and UT resources are released at the source AP.

  FIGS. 20-22 show the call flow for AxP handoff without mobility management (MM) relocation and without GN relocation. FIG. 20 illustrates handoff preparation. FIG. 21 illustrates handoff execution. FIG. 22 illustrates handoff completion. A description of the steps in the AxP handoff call flow follows.

  Referring first to FIG. 18, the call flow is between UT2002, source BxP2004, target BxP2006, source AxP2008, target AxP2012, mobility management (MM) 2014 (e.g., MM component), and GN2010. It is in. The initial packet data flow is represented by lines 2016, 2018, and 2020.

  In step 1, the source AxP2008 determines to hand over UT2002 to the target cell and target AxP2012 based on the satellite ephemeris information and the beam pattern.

  In step 2, the source AxP2008 sends a handoff required message to the MM2014 to request resource preparation at the target AxP2012. This message is sent to the target AxP2012's paging area identifier (PAI) (so that MM2014 can determine to which target AxP2012 the handoff request message should be sent in step 3) and the direct data transfer path (e.g., via the appropriate interface) Availability, UT radio resource configuration at source AxP2008, UT security configuration at source AxP2008, target cell ID (eg, target BxP ID indicating beam to be prepared), and radio bearer information Source-to-target transparent container (transparent through MM2014), carrying a handoff readiness information message with (including whether source AxP2008 proposes to forward forward link data) Included).

  In step 3, MM2014 sends a handoff request message to target AxP2012 to request resource preparation at target AxP2012. The message is a source-to-target transparent container carried in the handoff request message (see step 2), a list of data bearers to be set up (e.g. quality of service (QoS) information, GN tunneling protocol (TP) address per data bearer) Specified information), and security context information (eg, one NH, NCC pair for one-hop security during derivation by the target AxP of new security keys for user plane traffic and radio signaling).

  In step 4, when receiving the handoff request message from MM2014, the target AxP2012 determines that the UE context can be established.

  In step 5, the target AxP2012 sends a handoff request acknowledgment message to the MM2014 to inform the MM2014 about the resources prepared at the target AxP2012. This message includes a target-to-source transparent container (passed transparently through MM2014) that carries the handoff command message to be used by the source AxP2008 when constructing the radio connection reconfiguration message (see step 8). Handoff Request Acknowledgment messages also include target AxP downlink TP addressing on the specified interface per data bearer (for example, for data sent directly from GN2010 to target AxP2012, not via source AxP2008) Contains a list of data bearers to be set up, including information. The handoff request message is an additional target AxP2012 forward link TP addressing information per data bearer (if the source AxP2008 proposes to perform forward link data transfer for the data bearer and the target AxP2012 accepts the proposal). And includes target AxP reverse link TP addressing information per data bearer (if target AxP2012 requests source AxP2008 to perform reverse link data transfer for RL-AM data bearers) There is.

  In step 6, if indirect transfer of data is applied (eg, via a specified interface), MM2014 sends an indirect data transfer tunnel creation request message to GN2010. This message includes the data bearer ID, the target AxP tunnel ID and IP address for indirect transfer of forward link data on the specified interface, and the reverse link data on the specified interface, as appropriate. A list of data bearers, including information on the target AxP's tunnel ID and IP address for each indirect transfer for each data bearer. Subsequently, the GN 2010 transmits an indirect data transfer tunnel response creation message to the MM 2014. This message may optionally include the data bearer ID, the GN tunnel ID and IP address for indirect forwarding of forward link data on the specified interface, and the reverse link data on the specified interface. GN tunnel ID and IP address information for indirect transfer is included for each data bearer.

  In step 7, MM2014 sends a handoff command message to source AxP2008 to inform source AxP2008 that resources for handoff are received at target AxP2012. This message includes the target-to-source transparent container (see step 5) carried in the handoff request acknowledgment message to be used by the source AxP 2008 when constructing the radio connection reconfiguration message (see step 8). The handoff command message also includes a list of data bearers to be set up. If direct transfer of data is applied (e.g. via the appropriate interface), the message suggests that the source AxP2008 performs forward link data transfer for the data bearer and the target AxP2012 May include target AxP forward link TP addressing information per data bearer (if target AxP2012 requests source AxP2008 to perform reverse link data transfer for RL-AM data bearer) May include target AxP reverse link TP addressing information for each data bearer. If indirect transfer of data is applied (for example, via a specified interface), the message suggests that the source AxP2008 performs forward link data transfer for the data bearer and the target AxP2012 May include GN forward link TP addressing information for each data bearer (if target AxP2012 requests source AxP2008 to perform reverse link data transfer for RL-AM data bearer) May include GN reverse link TP addressing information for each data bearer. See step 6. The message also includes a new satellite and cell transition table. Upon receipt of the handoff command message, the source AxP2008 freezes the transmitter / receiver status for the UT data bearer.

  In step 8, the source AxP2008 sends a radio connection reconfiguration message to UT2002. This message includes the new UT-ID, PCI and frequency for the target BxP2006, security information, radio resource common and dedicated configuration information as needed (e.g., random access information, CQI reporting information), and target data Contains bearer configuration information (if there is a change from the current configuration). This message also includes a new paging area identifier that uniquely identifies the target AxP2012. When receiving the radio connection reconfiguration message from the source AxP2008, the UE starts timer T-4. When T-4 expires (eg, a handoff failure occurs), UT2002 performs a wireless connection re-establishment procedure.

  In step 9, UT2002 derives new KAXP, KUPenc, Kint, and Kenc to be used when performing a handoff to target AxP2012.

  Referring to FIG. 21, for the RL-AM data bearer, UT2002 resets the MAC state and the RL state (step 10). For the RL-UM data bearer, UT2002 resets the MAC, RL, and state. UT2002 then obtains a new cell (eg, FL sync).

  In steps 11 and 12, the source AxP2008 sends a UT status transfer message to the target AxP2012 via MM2014. The source AxP2008 sends this message to the target AxP2012 only if only at least one data bearer is configured for RL-AM operation. This message includes reverse link SN and FN receiver status, forward link SN and FN transmitter status, and (optionally) reverse link service data unit (SDU) reception status (target AxP2012 is RL-AM Information for the RL-AM data bearer is included for each RL-AM data bearer, requesting the source AxP 2008 to perform reverse link data transfer for the data bearer and the source AxP 2008 accepting the request. Also, for the RL-AM data bearer and the RL-UM data bearer, the source AxP2008 starts to forward forward link data (stored in the source AxP2008 data bearer buffer) to the target AxP2012 in order. For RL-AM data bearers, this includes all forward link SDUs with SNs for which the successful delivery of the corresponding PDU was not confirmed by UT2002 (eg, via the RL status PDU). For RL-AM and RL-UM data bearers, this also includes new forward link data arriving on the specified interface from GN2010. For the RL-AM data bearer to which the reverse link data transfer is applied, the source AxP2008 starts to transfer the reverse link SDU with the SN received out of order to the target AxP2012. For RL-AM data bearers to which reverse link data transfer is not applied, the source AxP 2008 discards reverse link SDUs received out of order. For the RL-UM data bearer, the source AxP2008 sends the reverse link SDU received out of order to the GN2010 via the specified interface. Note that when direct transfer of data is applied, the source AxP2008 transfers the data to the target AxP2012 over the appropriate interface.

  If indirect transfer of data is applied, the source AxP 2008 transfers the data 2022 to the target AxP 2012 over the interface specified via GN2010. The transferred data is stored in the target AxP data bearer buffer (step 12).

  In step 12, UT2002 sends a contention-based random access preamble on random access to target BxP2006 (where source BxP2004 and target BxP2006 may be the same entity). When the random access preamble is received from UT2002, target BxP2006 verifies the received signature sequence. If a dedicated preamble signature is available in the target BxP2006 and UT2002 is assigned a dedicated preamble signature in step 8, UT2002 sends a contention-free random access preamble on random access to the target BxP2006, and the result There is no possibility of collision.

  In step 14, the target BxP2006 sends a random access response addressed to the appropriate RA-RNTI to UT2002. The random access response includes a paging area, an RL grant, and a temporary UT-ID.

  In the operation of block 2030, the UT 2002 sends a wireless connection reconfiguration complete message to the target AxP 2012 (step 15). This message does not include IE. The wireless connection reconfiguration complete message is integrity protected and encrypted using the new Kint and Kenc respectively, and the UD-ID MAC control element (CE), as well as the PAI MAC control element and location management information (LMI) MAC Sent with two new MAC control elements, the control elements. The UT-ID MAC control element includes the UT-ID assigned to UT2002 by the target AxP2012 in the radio connection reconfiguration message (see step 8). The PAI MAC control element includes the PAI assigned to UT2002 by the target AxP2012 in step 8. The LMI MAC control element contains the latest location information of the UT. Target BxP 2006 parses the PAI MAC control element to determine which AxP to which the wireless connection reconfiguration complete message should be forwarded. Target BxP 2006 may send a handoff notification message to MM 2014 at this time (eg, not step 19). UT2002 starts a contention resolution timer.

  In step 16, the target BxP2006 sends an RL grant for a new transmission to UT2002. The RL grant is addressed to the UT-ID assigned to UT2002 by the target AxP2012 in the radio connection reconfiguration message (see step 8). Upon receiving the RL grant from the target BxP2006, UT2002 stops the contention resolution timer and timer T-4. UT2002 may initiate transmitting reverse link signaling on signaling radio bearers (eg, SRB1 and SRB2) and reverse link data on all data radio bearers (DRB). UT2002 may also begin to receive forward link signaling on SRB1 and SRB2 and forward link forwarded data on all DRBs.

  Referring now to FIG. 22, for the RL-AM data bearer to which reverse link data transfer is applied, the target AxP2012 has a status including a list of missing reverse link PDUs and received reverse link PDUs. A report message is transmitted to UT2002 (step 17). Target AxP2012 uses the information in the UT status transfer message from source AxP2008 via MM2014 (see step 11) to construct a status report. Upon receiving a status report message from the target AxP 2012, UT2002 does not perform any retransmissions of any PDUs whose success has been confirmed by the status report message. After successful completion of the reverse link PDU retransmission, UT2002 begins to send a new RL-AM reverse link PDU to the target AxP2012. Since the reverse link SN is maintained for each RL-AM data bearer, the target AxP 2012 uses a window-based mechanism for delivery in the sequence and avoiding duplication. For the RL-UM data bearer, UT2002 starts sending a new RL-UM reverse link PDU to the target AxP2012. The upper packet data flow is represented by arrows 2032, 2034, and 2036.

  For all RL-AM data bearers that configured UT2002 to send a status report on the reverse link during re-establishment, UT2002 received the missing forward link PDU and received A status report message including a list of forward link PDUs is transmitted to the target AxP 2012 (step 18). Upon receipt of this message, the target AxP2012 starts to send the forward link PDU forwarded to the target AxP2012 by the source AxP2008 with and without the SN to the UE. This packet data flow is represented by arrows 2038 and 2040. The target AxP 2012 continues to do this until it receives one or more TP end marker packets from the source AxP 2008 for that RL-AM data bearer. The target AxP 2012 does not perform retransmission of any PDUs whose success has been confirmed by the status report message from UT2002. Since the forward link SN is maintained for each RL-AM data bearer, UT2002 uses a window-based mechanism for delivery in the sequence and avoiding duplication. For the RL-UM data bearer, the target AxP2012 sends the forward link PDU forwarded by the source AxP2008 to the target AxP2012 (without continuing the original SN because the SN is not maintained per RL-UM data bearer). Start sending to UT2002. The target AxP2012 continues to do this until it receives one or more TP end marker packets from the source AxP2008 for each RL-UM data bearer.

  Step 19 may be performed immediately after step 15. In step 19, target AxP2012 sends a handoff notification message to MM2014 to inform MM2014 that UT2002 has been identified in the target cell and that the handoff has been completed. This message includes the PAI and target cell ID of the target AxP2012 (eg, target BxP ID indicating the beam in which UT2002 was identified).

  In step 20, MM2014 transmits a bearer modification request message to GN2010. This message contains a list of data bearers, including information for each data bearer: data bearer ID, target AxP tunnel ID, and forward link user plane IP address (to uniquely identify the UT data bearer). Including.

  In step 21, the GN 2010 switches the forward link data path from the source AxP2008 to the target AxP2012 and sends one or more TP end marker packets 2042 for each data bearer to the source AxP2008. GN 2010 also starts transmitting forward link data addressed to UT 2002 directly to target AxP 2012 (arrows 2044 and 2046). The source AxP2008 transfers the TP end marker packet for each data bearer to the target AxP2012. Upon receiving a TP end marker packet for each data bearer from the source AxP 2008, the target AxP 2012 may start to transmit the received forward link data directly from the GN 2010 to the UT 2002. Note that if direct transfer of data is applied, the source AxP 2008 forwards the TP end marker packet 2048 to the target AxP 2012 over the appropriate interface. If indirect transfer of data is applied, the source AxP2008 transfers the data to the target AxP2012 via GN2010 (arrow 2050).

  In step 22, the GN 2010 transmits a bearer modification response message to the MM 2014. This message includes a list of data bearers that includes data bearer ID and cause (eg, request accepted) information for each data bearer.

  In step 23A, the MM 2014 sends a UE context release command message to the source AxP2008 requesting the release of the UT-related S1 logical connection on the S1 interface. Subsequently, in step 23B, the source AxP2008 sends a UE context release command message to the MM2014 to confirm the release of the UT related logical connection on the appropriate interface. In step 24, the source AxP 2008 releases UT radio resources and context. In step 25, the indirect data transfer tunnel request (from step 6) is deleted. The final packet data flow is represented by lines 2052, 2054, and 2056.

Using Satellite and Cell Transition Tables In some implementations, AxP can optionally specify UT position and / or velocity, satellite position, satellite beam / cell pattern, satellite beam / cell on / off schedule. Or one or more of the satellite indication errors may be used to generate and / or update the satellite and cell transition tables. The location and / or speed of the UT, if specified, can be sent by the UT via a wireless signaling message. The position of time over time can be obtained from the ephemeris data. For example, in a given satellite access network (SAN) that includes multiple GNs, the NOC / SOC in the SAN may provide updated satellite ephemeris information to all AxPs in the SAN.

  In some implementations, the system UTs a single row of the satellite and cell transition table (e.g., the row in Table 2 described above) to be used for connected mode handoff. provide. For example, the source AxP / BxP may include that single row of satellite and cell transition tables in the information element (IE) of the radio connection reconfiguration message sent to the UT while the UT is still on the serving cell. Thus, while a UT is being serviced by one cell / beam, the UT may receive satellite and cell transition information that the UT should use for transitioning to another cell / beam.

Configuration Messages in BxP Handoff As mentioned above, each satellite beam can be considered a separate cell with its own data and control channels and signals. When a UT is handed over from one cell to another, some of the radio configuration parameters that were in effect for the source cell may change due to the operation of the UT on the target cell Yes, it may need to be updated.

  The radio message used for radio reconfiguration of the radio parameters for the serving cell is also used to deliver updated configuration parameters for the target cell.

  AxP communicates the reconfiguration parameters for the target cell to the source cell (step 1 of FIG. 15 and also applicable to the distribution of wireless connection reconfiguration in FIGS. 16, 17, and 18). The reconfiguration message for the target cell is delivered to the UT by the source cell before the handoff occurs, as illustrated in step 1 of FIG. The message transmission needs to take place well before the handoff so that the UT has time to receive the message in a timely manner to allow reliable transmission. Upon receiving a reconfiguration message for the target cell, the UT stores it and applies the reconfiguration when it initiates communication on the target cell.

  Handoff is performed based on the handoff transition table (Table 4) and follows the procedure defined for BxP handoff. The new configuration is applied at the time of handoff so that the UT is properly configured for the new serving cell before the data and control exchange begins.

  The radio reconfiguration message for the target beam may include radio parameters that are UT specific (dedicated) and radio parameters that are cell specific (common). They are for dedicated, MAC configuration, discontinuous reception (DRX) parameters, power headroom reporting (PHR), buffer status reporting (BSR) scheduling request (SR), HARQ, SPS configuration, semi-persistent scheduling Parameters (cycle, resource), PHY configuration, dedicated PHY parameters for data channel and control channel power control, CQI report, sounding reference signal (SRS), SR, random access configuration, UT-ID, PCI, common radio resource configuration Common parameters for random access (preamble information, power control, management information, etc.), physical random access (route sequence information and physical random access configuration index, etc.), reference signal power and power control, RL reference signal, ACK / NACK and CQI mapping, SRS (bandwidth and subframe configuration, etc.), p-Max (in cell Used to limit RL RL transmit power). Since a UT-ID is provided to the UT for each serving cell, a 16-bit UT-ID may be sufficient to uniquely handle a defined number of approximately 5000 UTs per cell. Please keep in mind.

Radio link failure During normal operation, when a UT is handed off from one satellite or cell / beam to another satellite or cell / beam, there is no signaling for handoff between the GN entity supporting the handoff and the UT. Completed. A radio link failure (RLF) may be declared (eg, at the UT) if the UT loses communication with the GN before handoff signaling is complete. RLF can occur in the system for a variety of possible reasons, for example due to rain or snow attenuation effects, or due to shielding by buildings or trees, causing the UT to lose connection to the cell. In this case, the UT may utilize an RLF restoration mechanism to re-establish communication with the GN. The RLF procedure attempts to reconnect the UT to the same source cell or to a different (eg, target) cell.

  FIG. 23 shows an example of a call flow for the RLF procedure. This call flow is between UT2302, source BxP or target BxP2304, and source AxP or target AxP2306. A description of the call flow steps follows.

  In step 1, a radio link detection procedure is used to detect RLF (eg, problems with a radio link connection). This may occur at the physical layer (e.g. if the SNR is below a certain threshold), or at the MAC layer (e.g. when a certain number of packets are decoded incorrectly) or at the RL layer (e.g. The number of RL retransmissions) may be performed. The UT 2302 initiates a radio connection re-establishment procedure by initiating a target satellite and cell search and selection procedure.

  After the UT 2302 acquires the appropriate target satellite and cell (step 2), the UT 2302 sends a contention based random access preamble on random access to the target BxP 2304 (step 3). Upon receiving a random access preamble from UT 2302, target BxP 2304 verifies the received signature sequence. Target BxP2304 may be the same as source BxP (eg, UT2302 selects the same cell that UT2302 was connected to before the RLF occurred).

  In step 4, the target BxP 2304 sends a random access response addressed to the appropriate UT-ID to the UT 2302. The random access response includes a paging area, an RL grant, and a temporary UT-ID.

  In step 5, the UT 2302 sends a radio connection re-establishment request message to the appropriate target AxP 2306 along with two new MAC control elements (PAI MAC control element and LMI MAC control element). The radio connection re-establishment message includes the UT's old UT-ID, old PCI, and MAC-I for verification during the radio connection re-establishment procedure. The PAI MAC control element contains the latest PAI assigned to the UT 2302 by the source AxP. The PAI belongs to the target AxP if the handoff was in progress before the RLF, otherwise the PAI belongs to the source AxP. The LMI MAC control element contains the latest location information of the UT. The target BxP 2304 parses the PAI MAC control element and the LMI MAC control element to determine to which AxP the wireless connection re-establishment request message should be transferred. If the LMI MAC control element indicates an administrative region that is not handled by AxP mapped to the PAI MAC control element, the target BxP2304 forwards the radio connection re-establishment request message to the appropriate target AxP (this is Resulting in failure of the re-establishment procedure and causing the UT2302 to initiate a NAS restore procedure (eg, a service request procedure)). The UT2302 starts timer T-3. When T-3 expires (eg, the wireless connection re-establishment procedure fails), the UT 2302 executes the NAS service request procedure.

  In step 6, the target AxP 2306 sends a radio connection re-establish message to the UT 2302 along with the UE contention resolution identity MAC control element (to provide contention resolution). The radio connection re-establishment message includes security configuration information used by the UT 2302 to derive new control plane and user plane keys (see step 7). This message may also include SRB1 configuration information.

  In step 7, the UT 2302 derives new KAXP, KUPenc, Kint, and Kenc to be used with the re-established wireless connection.

  In step 8, the UT 2302 transmits a wireless connection re-establishment completion message to the target AxP 2306. This message does not include IE and is integrity protected and encrypted using the new Kint and Kenc respectively.

  In step 9, the target AxP 2306 sends a radio connection reconfiguration message to the UT 2302. This message includes SRB2 and DRB configuration information.

  In step 10, the UT 2302 sends a wireless connection reconfiguration complete message to the target AxP 2306. This message does not include IE. The final packet data flow is represented by lines 2312 and 2314.

Exemplary Operations With the above in mind, additional examples of operations that may be performed by the UT and / or GN in support of a UT handoff will now be described with respect to FIGS.

  FIG. 24 is a diagram illustrating an example process 2400 for generating and using satellite handoff information in accordance with certain aspects of the present disclosure. Process 2400 may be performed in a processing circuit that may be located in a GN or some other suitable device. In some implementations, the process 2400 represents the operations performed by the GN controller 250 of FIG. In some implementations, process 2400 represents operations performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). Of course, in various aspects within the scope of this disclosure, process 2400 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 2402, the GN (or other suitable device) optionally receives information from the user terminal. For example, the GN may receive user terminal capabilities and location information.

  At block 2404, generation of satellite handoff information is triggered at the GN (or other suitable device). This information may comprise some or all of the satellite and beam / cell transition tables. For example, the generation of the table may be triggered based on a user terminal handoff to a satellite or based on receipt of a measurement message from the user terminal.

  At block 2406, the GN (or other suitable device) generates satellite handoff information that specifies a handoff time for a particular beam of a particular satellite. For example, this information may be a table that indicates the timing for transitioning between cells / beams and satellites. In some aspects, the table is optionally based in part on the information received from the user terminal at block 2002.

  At block 2408, the GN (or other suitable device) transmits satellite handoff information to the user terminal.

  At block 2410, the GN (or other suitable device) performs a handoff for the user terminal to a different cell / beam and at least one satellite based on the satellite handoff information.

  FIG. 25 is a diagram illustrating an example process 2500 for using satellite handoff information in accordance with certain aspects of the present disclosure. Process 2500 may be performed in a processing circuit that may be located in a user terminal or some other suitable device. In some implementations, process 2500 represents the operations performed by control processor 420 of FIG. In some implementations, process 2500 represents operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 2500 may be performed by any suitable device capable of supporting communication-related operations.

  At block 2502, the user terminal (or other suitable device) optionally sends a measurement message.

  At block 2504, the user terminal (or other suitable device) receives satellite handoff information that specifies a handoff time for a particular beam of a particular satellite. For example, this information may be a table that indicates the timing for transitioning between cells / beams and satellites.

  At block 2506, the user terminal (or other suitable device) performs a handoff to a particular beam of a particular satellite (e.g., to a different cell / beam and at least one satellite) based on the satellite handoff information. To do.

  FIG. 26 is a diagram illustrating an example process 2600 for signaling user terminal capability information in accordance with certain aspects of the present disclosure. Process 2600 may be performed in a processing circuit that may be located in a user terminal or some other suitable device. In some implementations, process 2600 represents the operations performed by control processor 420 of FIG. In some implementations, process 2600 represents an operation performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 2600 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 2602, transmission of user terminal capability information is triggered at the user terminal (or other suitable device). For example, this transmission may be triggered as a result of an initial connection to the satellite.

  At block 2604, the user terminal (or other suitable device) generates a capability message. In some aspects, this message indicates whether the UT can sense multiple cells / beams and / or satellites, and / or this message is UT cell / beam tuning time and / or inter-satellite. Indicates the tuning time.

  At block 2606, the user terminal (or other suitable device) sends a capability message to the GN.

  FIG. 27 is a diagram illustrating an example process 2700 for using user terminal capabilities in accordance with certain aspects of the present disclosure. Process 2700 may be performed in a processing circuit that may be located in a GN or some other suitable device. In some implementations, process 2700 represents the operations performed by GN controller 250 of FIG. In some implementations, process 2700 represents an operation performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). Of course, in various aspects within the scope of this disclosure, process 2700 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 2702, the GN (or other suitable device) receives a capability message from the user terminal. This capability message includes user terminal capability information.

  At block 2704, the GN (or other suitable device) generates satellite handoff information. For example, a table or a portion of a table is generated based in part on user terminal capability information (e.g., tuning time), user terminal location information, satellite movement, ephemeris information, and constraints due to the operating system. obtain.

  At block 2706, the GN (or other suitable device) selects a handoff procedure for the user terminal based in part on the user terminal capability information. For example, monitoring measurement messages from a user terminal may be enabled or disabled based on whether the user terminal supports dual sensing. Thus, the device may enable or disable the device from monitoring measurement messages based on the user terminal capability information.

  FIG. 28 is a diagram illustrating an example process 2800 for signaling user terminal location information in accordance with certain aspects of the present disclosure. Process 2800 may be performed in a processing circuit that may be located in a user terminal or some other suitable device. In some implementations, the process 2800 represents operations performed by the control processor 420 of FIG. In some implementations, process 2800 represents operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 2800 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 2802, transmission of user terminal location information is triggered at the user terminal (or other suitable device). This may be the result of an initial connection, or may be based on whether the UT exceeds a geographic boundary (geofensing), or may be based on whether an error limit has been exceeded.

  At block 2804, the user terminal (or other suitable device) generates a location message. In some aspects, this message may indicate the current position if the UT is stationary, or may indicate a motion vector if the UT is moving.

  At block 2806, the user terminal (or other suitable device) sends a location message to the GN.

  FIG. 29 is an illustration of an example process 2900 for using user terminal location information in accordance with certain aspects of the present disclosure. Process 2900 may be performed in a processing circuit that may be located in a GN or some other suitable device. In some implementations, process 2900 represents the operations performed by GN controller 250 of FIG. In some implementations, process 2900 represents an operation performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). Of course, in various aspects within the scope of this disclosure, process 2900 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 2902, the GN (or other suitable device) receives a location message from the user terminal. This location message includes user terminal location information.

  At block 2904, the GN (or other suitable device) generates satellite handoff information based in part on the user terminal location information. For example, if the UT is stationary, the GN may generate a table or table portion based on the current UT position. As another example, if the UT is moving, the GN may generate a table (or portion) based on the UT motion vector.

  FIG. 30 is a diagram illustrating an example user terminal handoff process 3000 in accordance with certain aspects of the present disclosure. Process 3000 may be performed in a processing circuit that may be located in a user terminal or some other suitable device. In some implementations, process 3000 represents the operations performed by control processor 420 of FIG. In some implementations, process 3000 represents operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 3000 may be performed by any suitable device capable of supporting communication-related operations.

  At block 3002, the next user terminal handoff is indicated at the user terminal (or other suitable device). For example, handoff may be indicated based on satellite handoff information.

  At block 3004, the user terminal (or other suitable device) measures a satellite signal (eg, a signal from the satellite indicated in the satellite handoff information).

  At block 3006, the user terminal (or other suitable device) determines whether to send a measurement message. In some aspects, this determination may be based on whether the current cell / beam and / or satellite signal is inappropriate, or whether the target cell / beam and / or satellite signal is inappropriate. Can be involved.

  In block 3008, if appropriate, the user terminal (or other suitable device) sends a measurement message and receives new satellite handoff information. In some aspects, this message may include measurement data and / or a request to advance / delay handoff timing. Thus, in some aspects, the user terminal may send a measurement message based on the signal measured at block 3004 and receive satellite handoff information as a result of sending the measurement message.

  At block 3010, the user terminal (or other suitable device) hands off to the target cell / beam and / or satellite according to the satellite handoff information.

  FIG. 31 is a diagram illustrating an example of a GN handoff process 3100 according to some aspects of the present disclosure. Process 3100 may be performed in a processing circuit that may be located in a GN or some other suitable device. In some implementations, process 3100 represents the operations performed by GN controller 250 of FIG. In some implementations, process 3100 represents operations performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). Of course, in various aspects within the scope of this disclosure, process 3100 may be performed by any suitable device capable of supporting communication-related operations.

  At block 3102, the GN (or other suitable device) receives a measurement message from the user terminal.

  At block 3104, the GN (or other suitable device) determines whether to modify the satellite handoff information based on the measurement message.

  In block 3106, if appropriate, the GN (or other suitable device) modifies the satellite handoff information (e.g., advances or delays the timing of the transition) and sends the modified satellite handoff information to the user terminal. .

  At block 3108, the GN (or other suitable device) performs handoff of the user terminal according to the satellite handoff information.

  FIG. 32 is a diagram illustrating another example of an inter-satellite handoff signaling process 3200 in accordance with certain aspects of the present disclosure. Process 3200 may be performed in a processing circuit that may be located in a GN, user terminal, or some other suitable device. In some implementations, process 3200 represents one or more operations performed by GN controller 280 of FIG. In some implementations, the process 3200 represents one or more operations performed by the control processor 420 of FIG. In some implementations, process 3200 represents one or more operations performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). In some implementations, process 3200 represents one or more operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 3200 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 3202, a user terminal (or other suitable device) connects to a first satellite controlled by a first NAC in the GN.

  At block 3204, a handoff of a user terminal (or other suitable device) to a second satellite controlled by a second NAC in the GN is indicated.

  At block 3206, the second NAC (or other suitable device) generates satellite handoff information for the user terminal.

  At block 3208, the second NAC (or other suitable device) transmits satellite handoff information to the first NAC.

  At block 3210, the first NAC (or other suitable device) transmits satellite handoff information to the user terminal.

  At block 3212, the user terminal (or other suitable device) is handed off to the second satellite according to the satellite handoff information.

  FIG. 33 is a diagram illustrating an example process 3300 for signaling ephemeris information in accordance with certain aspects of the present disclosure. Process 3300 may be performed in a processing circuit that may be located in a GN, user terminal, or some other suitable device. In some implementations, the process 3300 represents one or more operations performed by the GN controller 250 of FIG. In some implementations, process 3300 represents one or more operations performed by control processor 420 of FIG. In some implementations, process 3300 represents one or more operations performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). In some implementations, process 3300 represents one or more operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 3300 may be performed by any suitable device capable of supporting communication-related operations.

  At block 3302, the GN (or other suitable device) transmits ephemeris information to the user terminal.

  At block 3304, the user terminal (or other suitable device) receives the ephemeris information.

  At block 3306, the user terminal (or other suitable device) uses the ephemeris information to synchronize with the satellite.

  FIG. 34 is a diagram illustrating an example radio link failure process 3400 in accordance with certain aspects of the present disclosure. Process 3400 may be performed in a processing circuit that may be located in a user terminal or some other suitable device. In some implementations, process 3400 represents the operations performed by control processor 420 of FIG. In some implementations, process 3400 represents operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 3400 may be performed by any suitable device capable of supporting communication-related operations.

  At block 3402, the user terminal (or other suitable device) loses connection to the cell / beam or satellite.

  At block 3404, the user terminal (or other suitable device) enters a radio link failure mode.

  At block 3406, the user terminal (or other suitable device) identifies an alternative cell / beam and / or satellite (eg, based on ephemeris information stored at the user terminal).

  At block 3408, the user terminal (or other suitable device) establishes a connection using an alternative cell / beam and / or satellite.

  At block 3410, the user terminal (or other suitable device) communicates with the GN via the new connection.

  At block 3412, the user terminal (or other suitable device) exits the radio link failure mode.

  FIG. 35 is a diagram illustrating an example measurement gap related process 3500 in accordance with certain aspects of the present disclosure. Process 3500 may be performed in a processing circuit that may be located in a GN or some other suitable device. In some implementations, process 3500 represents the operations performed by GN controller 250 of FIG. In some implementations, process 3500 represents operations performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). Of course, in various aspects within the scope of this disclosure, process 3500 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 3502, the GN (or other suitable device) determines whether a measurement gap for measuring satellite signals is required.

  In block 3504, if no measurement gap is required, the GN (or other suitable device) does not include the detuning time in the satellite handoff information.

  In block 3506, if a measurement gap is needed, the GN (or other suitable device) determines the measurement gap to be used to measure the satellite signal.

  At block 3508, the GN (or other suitable device) transmits information indicating the measurement gap to the user terminal.

  FIG. 36 is a diagram illustrating an example measurement gap related process 3600 in accordance with certain aspects of the present disclosure. Process 3600 may be performed in a processing circuit that may be located in a user terminal or some other suitable device. In some implementations, process 3600 represents the operations performed by control processor 420 of FIG. In some implementations, process 3600 represents operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 3600 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 3602, a user terminal (or other suitable device) receives information indicating a measurement gap for measuring a satellite signal (eg, from a GN).

  At block 3604, the user terminal (or other suitable device) measures signals from at least one satellite during a measurement gap (indicated by the received information).

  FIG. 37 is a diagram illustrating an example user queue process 3700 in accordance with certain aspects of the present disclosure. Process 3700 may be performed in a processing circuit that may be located in a GN or some other suitable device. In some implementations, process 3700 represents the operations performed by GN controller 250 of FIG. In some implementations, process 3700 represents operations performed by apparatus 4600 of FIG. 46 (eg, by processing circuit 4610). Of course, in various aspects within the scope of this disclosure, process 3700 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 3702, the GN (or other suitable device) determines the time for user terminal handoff.

  At block 3704, the GN (or other suitable device) forwards at least one user queue prior to handoff.

  FIG. 38 is a diagram illustrating an example random access process 3800 in accordance with certain aspects of the present disclosure. Process 3800 may be performed in a processing circuit that may be located in a user terminal or some other suitable device. In some implementations, process 3800 represents the operations performed by control processor 420 of FIG. In some implementations, process 3800 represents operations performed by apparatus 4900 of FIG. 49 (eg, by processing circuit 4910). Of course, in various aspects within the scope of this disclosure, process 3800 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 3802, the user terminal (or other suitable device) receives a dedicated preamble signature (eg, UT receives a dedicated preamble signature from the GN in a control channel command).

  At block 3804, the user terminal (or other suitable device) performs a non-contention based random access procedure using a dedicated preamble signature.

First Exemplary Apparatus FIG. 39 shows a block diagram of an exemplary hardware implementation of an apparatus 3900 configured to communicate in accordance with one or more aspects of the present disclosure. For example, apparatus 3900 may be embodied or implemented in a UT or any other type of device that supports satellite communications. Accordingly, in some aspects, device 3900 may be an example of UT400 or UT401 of FIG. In various implementations, the apparatus 3900 may be embodied or implemented in any other electronic device having satellite system components, vehicle parts, or circuitry.

  Apparatus 3900 includes a communication interface 3902 (eg, at least one transceiver), a storage medium 3904, a user interface 3906, a memory device (eg, memory circuit) 3908, and a processing circuit 3910 (eg, at least one processor). In various implementations, the user interface 3906 is one of a keypad, display, speaker, microphone, touch screen display, or one of several other circuits for receiving input from or sending output to the user. Or a plurality may be included.

  These components may be coupled to each other and / or arranged to be in electrical communication with each other via a signaling bus or other suitable component, generally represented by a connection line in FIG. The signaling bus may include any number of interconnect buses and bridges depending on the specific application of the processing circuit 3910 and the overall design constraints. The signaling bus connects the various circuits together such that each of the communication interface 3902, storage medium 3904, user interface 3906, and memory device 3908 are coupled to and / or in electrical communication with the processing circuit 3910. connect. The signaling bus can also connect various other circuits (not shown) such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, Therefore, no further explanation will be given.

  Communication interface 3902 provides a means for communicating with other devices over transmission media. In some implementations, the communication interface 3902 includes circuitry and / or programming adapted to facilitate bidirectional communication of information to one or more communication devices in the network. In some implementations, the communication interface 3902 is adapted to facilitate wireless communication of the device 3900. In these implementations, the communication interface 3902 may be coupled to one or more antennas 3912 as shown in FIG. 39 for wireless communication within the wireless communication system. Communication interface 3902 may be configured with one or more stand-alone receivers and / or transmitters and one or more transceivers. In the example shown, communication interface 3902 includes a transmitter 3914 and a receiver 3916. The communication interface 3902 functions as an example of a means for receiving and / or a means for transmitting.

  Memory device 3908 may represent one or more memory devices. As shown, memory device 3908 may maintain idle mode handoff information 3918 along with other information used by apparatus 3900. In some implementations, the memory device 3908 and the storage medium 3904 are implemented as a common memory component. Memory device 3908 may also be used to store data that is manipulated by processing circuitry 3910, or some other component of apparatus 3900.

  Storage medium 3904 is one or more computer readable, machine readable, and computer readable code for storing programming, such as processor executable code or instructions (e.g., software, firmware), electronic data, databases, or other digital information. / Or may represent a processor readable device. Storage medium 3904 may also be used to store data that is manipulated by processing circuitry 3910 when performing programming. Storage medium 3904 is accessed by a general purpose or special purpose processor including a portable or fixed storage device, an optical storage device, and various other media capable of storing or containing or carrying programming. Any available media that can be used.

  By way of example, and not limitation, storage medium 3904 includes magnetic storage devices (eg, hard disks, floppy disks, magnetic strips), optical disks (eg, compact disks (CDs) or digital versatile disks (DVDs)), smart cards, flash memory. Device (for example, card, stick, or key drive), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), register , Removable disks, and any other suitable medium for storing software and / or instructions that can be accessed and read by a computer. The storage medium 3904 may be embodied in a manufactured product (eg, a computer program product). By way of example, a computer program product may include a computer readable medium in packaging material. In view of the above, in some implementations, the storage medium 3904 may be a non-transitory (eg, tangible) storage medium.

  Storage medium 3904 may be coupled to processing circuit 3910 such that processing circuit 3910 can read information from, and write information to, storage medium 3904. That is, storage medium 3904 may be an example in which at least one storage medium is integral with processing circuit 3910 and / or an example in which at least one storage medium is separated from processing circuit 3910 (e.g., in device 3900). Storage medium 3904 can be coupled to processing circuit 3910 so that it is at least accessible by processing circuit 3910, including examples that exist external to device 3900, examples that are distributed across multiple entities, and the like.

  The programming stored by storage medium 3904, when executed by processing circuit 3910, causes processing circuit 3910 to perform one or more of the various functions and / or processing operations described herein. . For example, the storage medium 3904 is configured to coordinate the operation in one or more hardware blocks of the processing circuit 3910, as well as to utilize the communication interface 3902 for wireless communication utilizing their respective communication protocols. In addition, operations may be included.

  The processing circuit 3910 is generally adapted for processing including execution of such programming stored in the storage medium 3904. The term “code” or “programming” as used herein is referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. But not limited to, instructions, instruction set, data, code, code segment, program code, program, programming, subprogram, software module, application, software application, software package, routine, subroutine, object Should be interpreted broadly to include executables, threads of execution, procedures, functions, etc.

  The processing circuit 3910 is configured to acquire, process, and / or transmit data, control access and storage of data, issue instructions, and control desired operations. Processing circuit 3910 may include circuitry configured to implement the desired programming provided by a suitable medium in at least one example. For example, the processing circuit 3910 may be implemented as one or more processors, one or more controllers, and / or other structures configured to perform executable programming. Examples of processing circuitry 3910 are general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic components, individual gate or transistor logic, individual hardware Hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may include a microprocessor, as well as any conventional processor, controller, microcontroller, or state machine. The processing circuit 3910 also includes a computing device such as a combination of DSP and microprocessor, several microprocessors, one or more microprocessors working with a DSP core, ASICs and microprocessors, or any other number of different configurations. Can be implemented as a combination of wing components. These examples of processing circuitry 3910 are for illustrative purposes and other suitable configurations within the scope of this disclosure are also contemplated.

  In accordance with one or more aspects of the present disclosure, processing circuit 3910 may be any of features, processes, functions, operations, and / or routines for any or all of the devices described herein. Or it can be adapted to do everything. For example, the processing circuit 3910 may be configured to perform any of the steps, functions, and / or processes described with respect to FIGS. 1-9 and 40-42. As used herein, the term “adapted” with respect to processing circuitry 3910 means that processing circuitry 3910 performs certain processes, functions, operations, and / or routines in accordance with various features described herein. It may refer to one or more of being configured to be used, so used, implemented so, and / or so programmed.

  The processing circuit 3910 is an application specific integrated circuit (e.g., a structure therefor) that functions as a means (e.g., a structure therefor) for performing any one of the operations described with respect to FIGS. 1-9 and 40-42. It can be a special processor such as ASIC). The processing circuit 3910 functions as an example of a means for transmitting and / or a means for receiving. In some implementations, the processing circuit 3910 may provide and / or incorporate at least a portion of the functionality of the control processor 420 of FIG.

  According to at least one example of apparatus 3900, processing circuit 3910 receives circuit / module 3920 for identifying, circuit / module 3922 for determining whether to transmit, circuit / module 3924 for transmitting, or receiving One or more of a circuit / module 3926 for handoff, a circuit / module 3928 for handoff, or a circuit / module 3930 for determining position information may be included. In various implementations, circuit / module 3920 for identifying, circuit / module 3922 for determining whether to transmit, circuit / module 3924 for transmitting, circuit / module 3926 for receiving, for handoff The circuit / module 3928 or the circuit / module 3930 for determining position information may provide and / or incorporate at least part of the functionality of the control processor 420 of FIG.

  As described above, the programming stored by the storage medium 3904, when executed by the processing circuit 3910, causes the processing circuit 3910 to perform one of the various functions and / or processing operations described herein. Or run multiple. For example, programming may cause processing circuit 3910 to perform various functions, steps, and / or processes described herein with respect to FIGS. 1-9 and 40-42 in various implementations. it can. As shown in FIG. 39, the storage medium 3904 includes a code 3932 for specifying, a code 3934 for determining whether to transmit, a code 3936 for transmitting, a code 3938 for receiving, and a handoff One or more of code 3940 or code 3942 for determining location information may be included. In various implementations, a code 3932 for identifying, a code 3934 for determining whether to transmit, a code 3936 for transmitting, a code 3938 for receiving, a code 3940 for handing off, or location information Code for determining 3942, circuit / module 3920 for identifying, circuit / module 3922 for determining whether to transmit, circuit / module 3924 for transmitting, circuit / module 3926 for receiving, handoff Can be implemented or otherwise used to provide the functionality described herein for the circuit / module 3928 for performing or the circuit / module 3930 for determining location information.

  A circuit / module 3920 for identifying is adapted to perform some function related to identifying information associated with at least one handoff entry, for example, and / or programming (e.g., in storage medium 4604). A stored code 3932) may be included. In some aspects, the identifying circuit / module 3920 (eg, means for identifying) may correspond to, for example, a processing circuit.

  In some implementations, the identifying circuit / module 3920 identifies the time associated with the handoff entry. For example, the identifying circuit / module 3920 may identify the time based on an idle mode handoff table (eg, Table 1). Here, the idle mode handoff table may include an entry indicating the start time of handoff to a particular satellite. To this end, the identifying circuit / module 3920 obtains entry information (eg, from the memory device 3908, the receiving circuit / module 3926, or some other component of the apparatus 3900). The circuit / module 3920 for identification may then process this information to determine the time (eg, frame number) associated with the entry. The circuit / module 3920 for identifying then generates an instruction for this decision (e.g., indicating time) and a component of the device 3900 (e.g., a circuit / module 3922 for determining whether to transmit) , Memory device 3908, or some other component).

  In some implementations, the identifying circuit / module 3920 identifies the amount of valid entries in the set of handoff entries. For example, the identifying circuit / module 3920 may determine how many valid entries remain in the idle mode handoff table (eg, Table 1). For this purpose, the identifying circuit / module 3920 obtains handoff entry information (eg, from the memory device 3908, the receiving circuit / module 3926, or some other component of the apparatus 3900). In some scenarios, the identifying circuit / module 3920 may process this information to determine the number of valid entries remaining in the table (e.g., after an entry has expired the table If left in). For example, the identifying circuit / module 3920 compares the time value (eg, handoff time) for each entry with the current time, thereby determining which entry represents the time that has not yet elapsed. Can do. In some scenarios, the identifying circuit / module 3920 may process this information to determine the total number of entries remaining (eg, if an entry is removed from the table when it expires). In any case, the identifying circuit / module 3920 generates an indication of this decision (e.g., a count indicating the determined amount) and determines whether this indication is transmitted to a component of the device 3900 (e.g., whether to send it). Circuit / module 3922, memory device 3908, or some other component for determination).

  A circuit / module 3922 for determining whether to transmit is adapted to perform several functions related to, for example, determining whether to transmit information and / or programming (e.g., storage medium) Code 3934) for determining whether to transmit stored in 3904 may be included. In some aspects, the circuit / module 3922 for determining whether to transmit (eg, means for determining whether to transmit) may correspond to, for example, a processing circuit.

  In some implementations, the information to be transmitted may include a request for an updated set of handoff entries. In some scenarios, the circuit / module 3922 for deciding whether to transmit makes a transmission decision (e.g., from the circuit / module 3920 for identifying, the memory device 3908, or some other component) To get information used to

  In some scenarios, the circuit / module 3922 for determining whether to transmit may obtain an indication of the time associated with a particular entry in the set of handoff entries. In this case, the circuit / module 3922 for deciding whether to transmit should update the set of handoff entries (e.g. due to a low number of valid entries in the table). Based on whether or not the time indicates something, it may be decided whether to send the request. For example, sending a request may be triggered when the difference between the current time and the indicated time is less than a threshold period.

  In some scenarios, the circuit / module 3922 for determining whether to transmit may obtain an indication of the amount of valid entries in the set of handoff entries. In this case, the circuit / module 3922 for deciding whether to transmit should update the set of handoff entries (e.g. due to a low number of valid entries in the table). Based on whether the amount indicates that there is, it may be decided whether to send the request. For example, sending a request may be triggered when the number of valid entries is less than a threshold count (eg, 1 or 2 or some other amount).

  In any scenario, the circuit / module 3922 for deciding whether to transmit generates the decision instruction above, and this instruction, for the circuit / module 3924 for transmitting, the memory device 3908, or the apparatus 3900 Send to some other component.

  Circuits / modules 3924 for transmitting are adapted to perform several functions related to, for example, sending (e.g., outputting or transmitting) information and / or programming (e.g., stored in storage medium 3904). Code 3936) to be transmitted. In some implementations, the circuit / module 3924 for transmitting is transmitted (e.g., from the circuit / module 3922 for determining whether to transmit, the memory device 3908, or some other component of the apparatus 3900). An instruction to trigger can be obtained. In some implementations, the circuit / module 3924 for transmitting is a circuit / module 3920 for identifying, a circuit / module 3930 for determining location information, a memory device 3908, or some other configuration of the apparatus 3900. From the element, information to be transmitted (eg, request message, indication, location information, etc.) can be obtained and the information processed (eg, encoded for transmission). In some scenarios, the circuit / module 3924 for transmitting provides information to another component (e.g., transmitter 3914, communication interface 3902, or some other component) that transmits information to another device. To do. In some scenarios (e.g., when the circuit / module 3924 for transmitting includes a transmitter), the circuit / module 3924 for transmitting is radio frequency signaling or some other type suitable for applicable communication media Information is sent directly to another device (eg, final destination) via

  The circuit / module 3924 for transmitting (eg, means for transmitting) may take a variety of forms. In some aspects, the circuit / module 3924 for transmitting may correspond to, for example, a processing circuit as discussed herein. In some aspects, the circuit / module 3924 for transmitting may include, for example, an interface (eg, bus interface, transmission interface, or some other type of signal interface), communication device, transceiver, transmitter, or specification herein. May correspond to some other similar component as discussed in. In some implementations, the communication interface 3902 includes circuitry / module 3924 for transmitting and / or code 3936 for transmitting. In some implementations, the circuit / module 3924 for transmitting and / or the code 3936 for transmitting is configured to control the communication interface 3902 (e.g., a transceiver or transmitter) to transmit information. The

  A circuit / module 3926 for receiving, for example, circuitry and / or programming adapted to perform some function related to receiving information (e.g., stored on storage medium 3904 for receiving) Code 3938). This information may include, but is not limited to, instructions, a set of handoff entries, a handoff table, and the like. In some scenarios, circuit / module 3926 for receiving obtains information (e.g., from communication interface 3902, memory device, or some other component of apparatus 3900) and processes the information (e.g., decoding). Can do. In some scenarios (e.g., if the circuit / module 3926 to receive is or includes an RF receiver), the circuit / module 3926 to receive information directly from the device that transmitted the information. Can be received. In any case, the circuit / module 3926 for receiving the acquired information is another component of the device 3900 (e.g., the circuit / module 3928 for handing off, the memory device 3908, or some other component). Can be output.

  The circuit / module 3926 for receiving (eg, means for receiving) may take a variety of forms. In some aspects, the circuit / module 3926 for receiving includes, for example, an interface (e.g., a bus interface, a transmit / receive interface, or some other type of signal interface), a communication device, a transceiver, a receiver, or a book It may correspond to any other similar component as discussed in the specification. In some implementations, the communication interface 3902 includes circuitry / module 3926 for receiving and / or code 3938 for receiving. In some implementations, the circuit / module 3926 for receiving and / or the code 3938 for receiving is configured to control the communication interface 3902 (e.g., a transceiver or receiver) to receive information. The

  Circuit / module 3928 for handoff is a circuit and / or programming adapted to perform several functions related to performing a handoff for a user terminal to a target cell, beam, or satellite, for example ( For example, the code 3940 for handoff stored in the storage medium 3904 may be included. In some aspects, the circuit / module 3928 for handoff (eg, means for handoff) may correspond to, for example, a processing circuit.

  In some implementations, based on a set of handoff entries (e.g., Table 1), the circuit / module 3928 for handoff may include one of a target satellite, target cell, or target beam or Identify multiple. For this purpose, the circuit / module 3928 for handoff collects this information and processes this information to identify the target (and optionally at least one carrier frequency of the target) and to target the user terminal. The communication parameters of device 3900 can be reconfigured to communicate. For example, the circuit / module 3928 for handoff may determine whether to handoff to a particular cell of a particular satellite at a particular time based on timing information in the set of handoff entries. As another example, the handoff circuit / module 3928 determines whether to handoff to a specific cell of a specific satellite on a specific carrier frequency based on frequency information in the set of handoff entries. Can do. If handoff is indicated, the circuit / module 3928 for handoff may initiate handoff signaling accordingly.

  Circuit / module 3930 for determining position information may be, for example, circuitry and / or programming adapted to perform several functions related to determining device position information (e.g., stored in storage medium 3904). May include code 3942) for determining location information. In some aspects, a circuit / module 3930 for determining position information (eg, means for determining position information) may correspond to, for example, a processing circuit.

  In some scenarios, the circuit / module 3930 for determining position information obtains information about at least one position of the device. For example, the circuit / module 3930 for determining position information may obtain global positioning system (GPS) coordinates indicating the current position of the device from a GPS receiver. As another example, circuit / module 3930 for determining location information may obtain a set of global positioning system (GPS) coordinates from a GPS receiver that indicate device movement (e.g., the path traveled by the device). . In some scenarios, this acquired information may constitute location information. In some scenarios, the circuit / module 3930 for determining position information processes this acquired information to generate position information (e.g., by generating a vector indicating speed indication or motion). Can do. Finally, the circuit / module 3930 for determining position information outputs the position information to the circuit / module 3924 for transmission, the memory device 3908, or some other component of the apparatus 3900.

First Exemplary Process FIG. 40 illustrates a process 4000 for communication according to some aspects of the present disclosure. Process 4000 may be performed within a processing circuit (eg, processing circuit 3910 of FIG. 39) that may be located in the UT or some other suitable device. Of course, in various aspects within the scope of this disclosure, process 4000 may be performed by any suitable device capable of supporting communication-related operations.

  At block 4002, a device (eg, UT) identifies a time associated with a particular entry in the set of handoff entries. In some aspects, the set of handoff entries may identify a set of satellites for device handoff. In some aspects, the time may include a start time for handoff to one satellite of the set of satellites. In some aspects, that particular entry may include the last entry in the set of handoff entries.

  The set of handoff entries can take different forms in different implementations. In some aspects, the set of handoff entries may include an idle mode handoff table. In some aspects, this time may indicate when the device should handoff to one satellite in the set of satellites while the device is in idle mode. In some aspects, the idle mode handoff table may include a time for a device in idle mode to handoff to the satellite for each satellite. In some aspects, that set of satellites may be for idle mode operation of the device. In some aspects, the set of handoff entries may include a time for each satellite to be handed off to a satellite by a device in idle mode.

  In block 4004, the device determines whether to send a request for an updated set of handoff entries based on the specified time in block 4002.

  In block 4006, the device sends a request for an updated set of handoff entries if the decision is to send a request. In some aspects, the request may be communicated when the device establishes a wireless connection with a terrestrial network (GN).

  In some aspects, the apparatus may perform any of the operations discussed above for FIG. 40, or any combination thereof.

Second Exemplary Process FIG. 41 illustrates a process 4100 for communication according to some aspects of the present disclosure. Process 4100 may be performed within a processing circuit (eg, processing circuit 3910 of FIG. 39) that may be located in the UT or some other suitable device. Of course, in various aspects within the scope of this disclosure, process 4100 may be performed by any suitable device capable of supporting communication-related operations.

  At block 4102, a device (eg, UT) identifies the amount of valid entries in the set of handoff entries. In some aspects, the set of handoff entries may identify a set of satellites for device handoff.

  The set of handoff entries can take different forms in different implementations. In some aspects, the set of handoff entries may include an idle mode handoff table. In some aspects, that set of satellites may be for idle mode operation of the device. In some aspects, the set of handoff entries may specify a time for a device in idle mode to handoff to each satellite in the set of satellites. In some aspects, the set of handoff entries may include a time for each satellite to be handed off to a satellite by a device in idle mode.

  In block 4104, the device determines whether to send a request for an updated set of handoff entries based on the specified amount. In some aspects, determining whether to send a request for an updated set of handoff entries may include determining whether the set of handoff entries includes only one valid entry.

  In block 4106, the device sends a request for an updated set of handoff entries if the decision is to send a request. In some aspects, the request may be communicated when the device establishes a wireless connection with a terrestrial network (GN).

  In some aspects, the apparatus may perform any of the operations discussed above for FIG. 41, or any combination thereof.

Third Exemplary Process FIG. 42 illustrates a process 4200 for communication according to some aspects of the present disclosure. One or more aspects of process 4200 may be used with (eg, in addition to or as part of) process 4000 of FIG. 40 or process 4100 of FIG. Process 4200 may be performed within a processing circuit (eg, processing circuit 3910 of FIG. 39) that may be located in the UT or some other suitable device. Of course, in various aspects within the scope of this disclosure, process 4200 may be performed by any suitable apparatus capable of supporting communication-related operations.

  In optional block 4202, a device (eg, UT) may determine device (eg, UT) location information.

  In block 4204, the device sends a request (eg, to the GN) for an updated set of handoff entries.

  In optional block 4206, the device may send information with the request. For example, the device may send device location information, an indication of time associated with a particular entry in the set of handoff entries, an indication of valid time associated with the set of handoff entries, or any combination thereof.

  At block 4208, the device receives an updated set of handoff entries (eg, after sending a request at block 4202).

  In optional block 4210, the device may receive an indication of at least one carrier frequency that the next cell providing coverage for the device will use to transmit. For example, the UT may receive the nextCellTransmitFreq parameter from the GN (eg, via a BIB message). As discussed above, this parameter may include a list of possible frequencies, a single frequency, etc.

  At block 4212, the device hands off to the satellite identified by the updated set of handoff entries at the time indicated by the updated set of handoff entries. In the scenario using block 4210, this handoff may be performed at the indicated at least one carrier frequency.

  In some aspects, the apparatus may perform any of the operations discussed above for FIG. 42, or any combination thereof.

Second Exemplary Device FIG. 43 shows a block diagram of an exemplary hardware implementation of another device 4300 configured to communicate according to one or more aspects of the present disclosure. For example, apparatus 4300 may be embodied or implemented in a GN or some other type of device that supports wireless communication. Thus, in some aspects, device 4300 may be an example of GN200 or GN201 of FIG. In various implementations, apparatus 4300 may be embodied or implemented in a gateway, ground station, vehicle component, or any other electronic device having circuitry.

  Apparatus 4300 includes a communication interface (e.g., at least one transceiver) 4302, a storage medium 4304, a user interface 4306, a memory device 4308 (e.g., that stores idle mode handoff information 4318), and processing circuitry (e.g., at least one processor). ) 4310. In various implementations, the user interface 4306 is one of a keypad, display, speaker, microphone, touch screen display, or one of several other circuits for receiving input from or sending output to the user. Or a plurality may be included. Communication interface 4302 may be coupled to one or more antennas 4312 and may include a transmitter 4314 and a receiver 4316. In general, the components of FIG. 43 may be similar to the corresponding components of apparatus 3900 of FIG.

  In accordance with one or more aspects of the present disclosure, the processing circuitry 4310 is any of features, processes, functions, operations, and / or routines for any or all of the devices described herein. Or it can be adapted to do everything. For example, the processing circuit 4310 may be configured to perform one or more of the steps, functions, and / or processes described with respect to FIGS. 1-9, 44, and 45. The term “adapted” with respect to processing circuit 4310 means that processing circuit 4310 is configured to perform a particular process, function, operation and / or routine in accordance with various features described herein. , Utilized, implemented, and / or programmed.

  Processing circuit 4310 is an application specific integrated circuit that functions as a means (e.g., a structure therefor) for performing one or more of the operations described with respect to FIGS. 1-9, 44, and 45. It can be a special processor, such as (ASIC). The processing circuit 4310 functions as an example of a means for transmitting and / or a means for receiving. In various implementations, the processing circuit 4310 may provide and / or incorporate at least a portion of the functionality of the GN controller 250 of FIG.

  According to at least one example of apparatus 4300, processing circuit 4310 includes circuit / module 4320 for identifying, circuit / module 4322 for determining whether to transmit, circuit / module 4324 for transmitting, transmitting One of circuit / module 4326 for generating, circuit / module 4328 for generating, circuit / module 4330 for determining motion, or circuit / module 4332 for determining how many entries to send Multiple may be included. In various implementations, a circuit / module 4320 for identifying, a circuit / module 4322 for determining whether to transmit, a circuit / module 4324 for transmitting, a circuit / module 4326 for receiving, to generate The circuit / module 4328, the circuit / module 4330 for determining movement, or the circuit / module 4332 for determining how many entries to send provide at least part of the functionality of the GN controller 250 of FIG. And / or may be incorporated.

  As described above, programming stored by storage medium 4304, when executed by processing circuit 4310, causes processing circuit 4310 to perform one of the various functions and / or processing operations described herein. Or run multiple. For example, programming may be performed on the processing circuit 4310 in one of the various functions, steps, and / or processes described herein with respect to FIGS. 1-9, 44, and 45 in various implementations. One or more can be executed. As shown in FIG. 43, the storage medium 4304 includes a code 4340 for specifying, a code 4342 for determining whether to transmit, a code 4344 for transmitting, a code 4346 for receiving, and a code for generating One or more of a code 4348, a code 4350 for determining motion, or a code 4352 for determining how many entries to send may be included. In various implementations, code 4340 for identifying, code 4342 for determining whether to transmit, code 4344 for transmitting, code 4346 for receiving, code 4348 for generating, determining motion Code 4350 for, or code 4352 for determining how many entries to send, circuit / module 4320 for identifying, circuit / module 4322 for determining whether to send, circuit for sending / Module 4324, circuit to receive / module 4326, circuit to generate / module 4328, circuit to determine motion / module 4330, or circuit to determine how many entries to send / module 4332 Can be implemented or otherwise used to provide the functionality described herein.

  The circuit / module 4320 for identifying is adapted to perform several functions related to identifying information associated with at least one handoff entry, for example, and / or programming (e.g., in the storage medium 4604). A stored code 4340) may be included. In some aspects, the circuit / module 4320 for identifying (eg, means for identifying) may correspond to, for example, a processing circuit.

  In some implementations, the identifying circuit / module 4320 identifies a valid time associated with the set of handoff entries. For example, the identifying circuit / module 4320 may identify the validity time of an idle mode handoff table (eg, Table 1). For this purpose, the circuit / module 4320 for identifying may obtain time information from the memory device 4308, the circuit / module 4326 for receiving, or some other component of the apparatus 4300. In some scenarios, identifying the validity time may include receiving an indication of the validity time (eg, from another device such as a UT). In some scenarios, identifying valid times may include receiving an indication of the time associated with a particular entry (eg, the last entry) in the set of handoff entries. In some cases, the identifying circuit / module 4320 processes the obtained information to determine a valid time associated with the set of handoff entries. For example, the identifying circuit / module 4320 may identify a handoff time associated with the last entry in the idle mode handoff table. In any of these scenarios, the circuit / module 4320 for identifying thereby generates an indication of valid time and the component of the device 4300 (e.g., the circuit / module for determining whether to transmit) 4322, memory device 4308, or some other component).

  The circuit / module 4322 for determining whether to transmit is adapted to perform several functions related to, for example, determining whether to transmit information and / or programming (e.g., storage medium) Code 4342) for determining whether to transmit stored in 4304 may be included. In some aspects, the circuit / module 4322 for determining whether to transmit (eg, means for determining whether to transmit) may correspond to, for example, a processing circuit.

  In some implementations, the information to be transmitted may include a request for an updated set of handoff entries. In some scenarios, the circuit / module 4322 for determining whether to transmit is (e.g., the circuit / module 4320 for identifying, the circuit / module 4330 for determining motion, the memory device 4308, or some Get information used to make a transmission decision (from other components). In some scenarios, the circuit / module 4322 for determining whether to transmit may obtain an indication of valid time associated with the set of handoff entries. In this case, the circuit / module 4322 for deciding whether to send decides whether to send the request based on whether the set of handoff entries indicates an expiration time that should be updated. obtain. For example, the transmission of a request may be triggered when the handoff entry indicates that it has expired or will expire in the near future. In some scenarios, the circuit / module 4322 for determining whether to transmit may obtain an indication of the movement of another device (eg, UT). In this case, the circuit / module 4322 for determining whether to transmit may determine whether to transmit the request based on, for example, how fast the other device is moving. In any case, the circuit / module 4322 for deciding whether to transmit generates a decision indication and this indication (e.g., circuit / module 4324 for transmission, memory device 4308, or apparatus 4300 Output to some other component of

  A circuit / module 4324 for transmitting, for example, circuitry and / or programming adapted to perform a number of functions related to sending (e.g., outputting or transmitting) information (e.g., stored in storage medium 4304). A code 4344) to be transmitted. In some implementations, the circuit / module 4324 for transmitting is transmitted (e.g., from the circuit / module 4322 for determining whether to transmit, the memory device 4308, or some other component of the apparatus 4300). An instruction to trigger can be obtained. In some implementations, the circuit / module 4324 for transmitting is a circuit / module 4320 for identifying, a circuit / module 4330 for determining motion, a memory device 4308, or some other component of the apparatus 4300. From which information to be transmitted (eg, request messages, instructions, location information, etc.) can be obtained and processed (eg, encoded for transmission). In some scenarios, the circuit / module 4324 for transmitting provides information to another component (e.g., transmitter 4314, communication interface 4302, or some other component) that transmits information to another device. To do. In some scenarios (e.g., when the circuit / module 4324 for transmitting includes a transmitter), the circuit / module 4324 for transmitting is radio frequency signaling or some other type suitable for applicable communication media Information is sent directly to another device (eg, final destination) via

  The circuit / module for transmitting 4324 (eg, means for transmitting) may take various forms. In some aspects, the circuit / module 4324 for transmitting may correspond to, for example, a processing circuit as discussed herein. In some aspects, the circuit / module 4324 for transmitting includes, for example, an interface (e.g., a bus interface, a transmission interface, or some other type of signal interface), a communication device, a transceiver, a transmitter, or a specification herein. May correspond to some other similar component as discussed in. In some implementations, the communication interface 4302 includes a circuit / module 4324 for transmitting and / or a code 4344 for transmitting. In some implementations, the circuit / module 4324 for transmitting and / or the code 4344 for transmitting are configured to control the communication interface 4302 (e.g., a transceiver or transmitter) to transmit information. The

  A circuit / module 4326 for receiving, for example, circuitry and / or programming adapted to perform some function related to receiving information (e.g., stored on storage medium 4304 for receiving) Code 4346). This information can include, but is not limited to, instructions, location information, and the like. In some scenarios, circuit / module 4326 for receiving obtains information (e.g., from communication interface 4302, memory device, or some other component of apparatus 4300) and processes the information (e.g., decoding). Can do. In some scenarios (e.g., if the circuit / module 4326 to receive is or includes an RF receiver), the circuit / module 4326 to receive the information directly from the device that transmitted the information. Can be received. In any case, the circuit / module 4326 for receiving the obtained information is another component of the apparatus 4300 (e.g., the circuit / module 4328 for generating, the memory device 4308, or some other component). Can be output.

  The circuit / module for receiving 4326 (eg, means for receiving) may take various forms. In some aspects, the circuit / module 4326 for receiving is, for example, an interface (e.g., a bus interface, a transmit / receive interface, or some other type of signal interface), a communication device, a transceiver, a receiver, or a book It may correspond to any other similar component as discussed in the specification. In some implementations, the communication interface 4302 includes circuitry / module 4326 for receiving and / or code 4338 for receiving. In some implementations, the circuit / module 4326 for receiving and / or the code 4338 for receiving is configured to control the communication interface 4302 (e.g., a transceiver or receiver) to receive information. The

  A circuit / module 4328 for generating, for example, circuitry and / or programming adapted to perform some function related to generating a set of handoff entries (e.g., stored on storage medium 4304, Code 4348) for generating may be included. In some aspects, the circuit / module for generating 4328 (eg, means for generating) may correspond to, for example, a processing circuit.

  In some implementations, the circuit / module for generating 4328 generates a set of handoff entries based on location information of another device (eg, UT). For this purpose, circuit / module 4328 for generating may obtain this location information from circuit / module 4326 for receiving, communication interface 4302, memory device, or some other component of apparatus 4300. This allows the generating circuit / module 4328 to create an updated set of handoff entries (eg, Table 1) based on the satellite ephemeris information and location information. In some scenarios, the circuit / module 4328 for generating receives an indication of the number of handoff entries to transmit (eg, from the circuit / module 4332 for determining how many entries to transmit). The circuit / module 4328 for generating then outputs this information (eg, the circuit / module 4324 for transmitting, the memory device 4308, or some other component of the apparatus 4300).

  The circuit / module 4330 for determining motion is, for example, circuitry and / or programming adapted to perform several functions related to determining the motion of the device (e.g. stored in the storage medium 4304). Code 4350) for determining motion may be included. In some aspects, the circuit / module 4330 for determining motion (eg, means for determining motion) may correspond to, for example, a processing circuit.

  In some scenarios, the circuit / module 4330 for determining movement generates an indication of movement of another device (eg, UT) based on the position information of the other device. For this purpose, the circuit / module 4330 for determining motion may obtain this position information from the circuit / module 4326 for receiving, the communication interface 4302, the memory device, or some other component of the apparatus 4300. Thereby, the circuit / module 4330 for determining motion may process this acquired information to generate a motion indication (eg, by generating a speed indication or a vector indicating the motion). The circuit / module 4330 for determining motion then outputs an indication (eg, to the circuit / module 4324 for determining whether to transmit, the memory device 4308, or some other component of the apparatus 4300).

  Circuit / module 4332 for determining how many entries to send, for example, to perform several functions related to determining how many updated handoff entries should be sent to another device May include circuitry and / or programming adapted to (eg, code 4352 for determining how many entries are stored in storage medium 4304). In some aspects, a circuit / module 4332 for determining how many entries to transmit (eg, means for determining how many entries to transmit) may correspond to, for example, a processing circuit.

  In some scenarios, the circuit / module 4332 for determining how many entries to send determines the number of entries based on other device movements. For this purpose, the circuit / module 4332 for determining how many entries to send, obtains motion information from the circuit / module 4330, memory device, or some other component of the device 4300 for determining motion Can do. Thereby, the circuit / module 4332 for determining how many entries to send may process this obtained information to determine how many entries to send. For example, as discussed herein, fewer entries are sent to a UT that is moving relatively faster than a UT that is moving relatively slowly or that is sent to a stationary UT. obtain. Thus, in some aspects, determining the number of entries may be based on at least one motion threshold, mapping motion to the number of entries, or other criteria. The circuit / module 4332 for determining how many entries to send is then instructed on the number of entries to send (e.g., the circuit / module 4328 for generating, the memory device 4308, or some other of the apparatus 4300 Output).

Fourth Exemplary Process FIG. 44 illustrates a process 4400 for communication according to some aspects of the present disclosure. Process 4400 may be performed within a processing circuit (eg, processing circuit 4310 in FIG. 43) that may be located in the GN or some other suitable device. Of course, in various aspects within the scope of this disclosure, process 4400 may be performed by any suitable apparatus capable of supporting communication-related operations.

  At block 4402, a device (eg, GN) identifies a valid time associated with the set of handoff entries. In some aspects, the set of handoff entries may identify a set of satellites for handoff of another device (eg, UT). In some aspects, the valid time may indicate the length of time that the set of handoff entries is valid.

  The identification of the effective time can take different forms in different implementations. In some aspects, identifying the validity time may include receiving an indication of the validity time. In some aspects, determining the validity time includes receiving an indication of a time associated with a particular entry of the set of handoff entries, and determining an expiration time based on the received indication. obtain. In some aspects, identifying valid times may include determining a time associated with the last valid entry in the set of handoff entries.

  The set of handoff entries can take different forms in different implementations. In some aspects, the set of handoff entries may include an idle mode handoff table. In some aspects, the set of handoff entries may identify at least one satellite for idle mode operation of other devices. In some aspects, the set of handoff entries may specify a time for a device in idle mode to handoff to each satellite in the set of satellites. In some aspects, the set of handoff entries may include a time for each satellite to be handed off to a satellite by a device in idle mode. In some aspects, the set of handoff entries may include the last set of handoff entries sent by the device to other devices.

  In block 4404, the device determines whether to send an updated set of handoff entries based on the identified validity time of block 4402.

  In block 4406, the apparatus sends an updated set of handoff entries if the decision is to send an updated set of handoff entries.

  In some aspects, the apparatus may perform any of the operations discussed above for FIG. 44, or any combination thereof.

Fifth Exemplary Process FIG. 45 illustrates a process 4500 for communication according to some aspects of the present disclosure. One or more aspects of process 4500 may be performed in conjunction with (eg, in addition to, or as part of) process 4400 of FIG. Process 4500 may be performed within a processing circuit (eg, processing circuit 4310 in FIG. 43) that may be located in the GN or some other suitable device. Of course, in various aspects within the scope of this disclosure, process 4500 may be performed by any suitable apparatus capable of supporting communication-related operations.

  In optional block 4502, a device (eg, GN) may receive an indication of the time associated with a particular entry in the set of handoff entries.

  In optional block 4504, the device may receive position information of the device (eg, another device such as UT).

  In block 4506, the device generates an updated set of handoff entries (eg, based on location information and / or time indication).

  In optional block 4508, the device may determine the movement of the device (eg, another device such as UT) based on the location information.

  In optional block 4510, the device may determine whether to send an updated set of handoff entries (eg, based on location information and / or other device movements). In some aspects, a device may determine how many updated handoff entries to send (eg, based on other device movements).

  In block 4512, the device sends an updated set of handoff entries.

  In optional block 4514, the device may send an indication of at least one carrier frequency that the next cell providing coverage for other devices (eg, UT) will use.

  In some aspects, the apparatus may perform any of the operations discussed above for FIG. 45, or any combination thereof.

Third Exemplary Device FIG. 46 shows a block diagram of an exemplary hardware implementation of a device 4600 configured to communicate in accordance with one or more aspects of the present disclosure. For example, apparatus 4600 may be embodied or implemented in a UT or any other type of device that supports satellite communications. Thus, in some aspects, device 4600 may be an example of GN200 or GN201 of FIG. In various implementations, the apparatus 4600 may be embodied or implemented within a gateway, ground station, vehicle component, or any other electronic device having circuitry.

  Apparatus 4600 includes a communication interface (eg, at least one transceiver) 4602, a storage medium 4604, a user interface 4606, a memory device (eg, memory circuit) 4608, and a processing circuit (eg, at least one processor) 4610. In various implementations, the user interface 4606 is one of a keypad, display, speaker, microphone, touch screen display, or one of several other circuits for receiving input from or sending output to the user. Or a plurality may be included.

  These components may be coupled to each other and / or arranged to be in electrical communication with each other via a signaling bus or other suitable component schematically represented by a connection line in FIG. . The signaling bus may include any number of interconnect buses and bridges depending on the specific application of the processing circuit 4610 and the overall design constraints. The signaling bus connects the various circuits together such that each of the communication interface 4602, the storage medium 4604, the user interface 4606, and the memory device 4608 is coupled to and / or in electrical communication with the processing circuit 4610. connect. The signaling bus can also connect various other circuits (not shown) such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, Therefore, no further explanation will be given.

  Communication interface 4602 provides a means for communicating with other devices through a transmission medium. In some implementations, the communication interface 4602 includes circuitry and / or programming adapted to facilitate bidirectional communication of information to one or more communication devices in the network. In some implementations, the communication interface 4602 is adapted to facilitate wireless communication of the device 4600. In these implementations, the communication interface 4602 may be coupled to one or more antennas 4612 as shown in FIG. 46 for wireless communication within the wireless communication system. Communication interface 4602 may be configured with one or more stand-alone receivers and / or transmitters and one or more transceivers. In the illustrated example, communication interface 4602 includes a transmitter 4614 and a receiver 4616. The communication interface 4602 functions as an example of a means for receiving and / or a means for transmitting.

  Memory device 4608 may represent one or more memory devices. As shown, memory device 4608 may maintain satellite-related information 4618 along with other information used by apparatus 4600. In some implementations, the memory device 4608 and the storage medium 4604 are implemented as a common memory component. Memory device 4608 may also be used to store data that is manipulated by processing circuit 4610, or some other component of apparatus 4600.

  Storage medium 4604 is one or more computer readable, machine readable, and computer readable code for storing programming such as processor executable code or instructions (e.g., software, firmware), electronic data, databases, or other digital information, and the like. / Or may represent a processor readable device. Storage medium 4604 may also be used to store data that is manipulated by processing circuitry 4610 when performing programming. Storage medium 4604 is accessed by a general purpose or special purpose processor including a portable or fixed storage device, an optical storage device, and a variety of other media capable of storing or containing or carrying programming. Any available media that can be used.

  By way of example, and not limitation, storage medium 4604 includes magnetic storage devices (eg, hard disks, floppy disks, magnetic strips), optical disks (eg, compact disks (CDs) or digital versatile disks (DVDs)), smart cards, flash memory. Device (for example, card, stick, or key drive), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), register , Removable disks, and any other suitable medium for storing software and / or instructions that can be accessed and read by a computer. Storage medium 4604 may be embodied in an article of manufacture (eg, a computer program product). By way of example, a computer program product may include a computer readable medium in packaging material. In view of the above, in some implementations, the storage medium 4604 may be a non-transitory (eg, tangible) storage medium.

  Storage medium 4604 may be coupled to processing circuit 4610 such that processing circuit 4610 can read information from, and write information to, storage medium 4604. That is, storage medium 4604 may be an example in which at least one storage medium is integral with processing circuit 4610 and / or an example in which at least one storage medium is separated from processing circuit 4610 (e.g., in apparatus 4600). Storage medium 4604 may be coupled to processing circuit 4610 so that it is accessible at least by processing circuit 4610, including examples that reside outside device 4600, examples that are distributed across multiple entities, and the like.

  The programming stored by storage medium 4604, when executed by processing circuit 4610, causes processing circuit 4610 to perform one or more of the various functions and / or processing operations described herein. . For example, the storage medium 4604 is configured to coordinate the operation of one or more hardware blocks of the processing circuit 4610 as well as to utilize the communication interface 4602 for wireless communication utilizing their respective communication protocols. In addition, operations may be included.

  The processing circuit 4610 is generally adapted for processing including execution of such programming stored in the storage medium 4604. The term “code” or “programming” as used herein is referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. But not limited to, instructions, instruction set, data, code, code segment, program code, program, programming, subprogram, software module, application, software application, software package, routine, subroutine, object Should be interpreted broadly to include executables, threads of execution, procedures, functions, etc.

  The processing circuit 4610 is configured to acquire, process, and / or transmit data, control access and storage of data, issue instructions, and control desired operations. Processing circuit 4610 may include circuitry configured to implement the desired programming provided by a suitable medium in at least one example. For example, the processing circuit 4610 may be implemented as one or more processors, one or more controllers, and / or other structures configured to perform executable programming. Examples of processing circuitry 4610 include general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic components, individual gate or transistor logic, individual hardware Hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may include a microprocessor, as well as any conventional processor, controller, microcontroller, or state machine. The processing circuit 4610 may also be a computer such as a combination of DSP and microprocessor, several microprocessors, one or more microprocessors working with a DSP core, ASICs and microprocessors, or any other number of different configurations. Can be implemented as a combination of wing components. These examples of processing circuit 4610 are for illustrative purposes and other suitable configurations within the scope of this disclosure are also contemplated.

  In accordance with one or more aspects of the present disclosure, the processing circuit 4610 may be any of features, processes, functions, operations, and / or routines for any or all of the devices described herein. Or it can be adapted to do everything. For example, the processing circuit 4610 may include the steps and functions described with respect to FIGS. 11, 12, 15-24, 27, 29, 31-33, 35, 37, 47, and 48. And / or may be configured to perform one or more of the processes. As used herein, the term “adapted” with respect to processing circuit 4610 means that processing circuit 4610 performs certain processes, functions, operations, and / or routines in accordance with various features described herein. One or more of being configured to be used, so utilized, so implemented, and / or so programmed.

  The processing circuit 4610 is one of the operations described with respect to FIGS. 11, 12, 15-24, 27, 29, 31-33, 35, 37, 47, and 48. It may be a special processor, such as an application specific integrated circuit (ASIC) that functions as a means (eg, a structure therefor) for performing one or more. The processing circuit 4610 functions as an example of a means for transmitting and / or a means for receiving. In some implementations, the processing circuit 4610 incorporates the functionality of the GN controller 250 of FIG.

  According to at least one example of apparatus 4600, processing circuit 4610 includes: circuit / module 4620 for generating, circuit / module 4622 for transmitting, circuit / module 4624 for performing handoff, circuit for receiving / Module 4626, Circuit to determine whether to fix / Module 4628, Circuit to select / Module 4630, Circuit to determine time / Module 4632, Circuit to transfer / Module 4634, Measurement gap One or more of a circuit / module 4636 for determining, or a circuit / module 4638 for determining that a measurement gap is not required may be included. In various implementations, circuit / module 4620 to generate, circuit / module 4622 to transmit, circuit / module 4624 to perform handoff, circuit / module 4626 to receive, decide whether to modify Circuit / module 4628 for selecting, circuit / module 4630 for selecting, circuit / module 4632 for determining the time, circuit / module 4634 for transferring, circuit / module 4636 for determining the measurement gap, or A circuit / module 4638 for determining that a measurement gap is not necessary may correspond at least in part to the GN controller 250 of FIG.

  The circuit / module for generating 4620 performs several functions related to generating satellite and cell transition information specifying, for example, the time to start and end communication with a specific cell of a specific satellite Circuitry and / or programming adapted to do so (eg, code 4640 for generation stored in storage medium 4604). In some implementations, the circuit / module for generating 4620 calculates information (eg, data for Table 1) based on the satellite ephemeris data and user terminal location data. For this purpose, the circuit / module 4620 for generating collects this data, processes the data to generate that information, and sends that information to the components of the device 4600 (eg, memory device 4608). For example, for a given location of a user terminal, the circuit / module for generating 4620 may determine when a particular cell for a particular satellite is based on the location of the satellite and the direction and coverage of the satellite cell over time. It can be determined whether to provide coverage for the user terminal.

  The circuit / module 4622 for transmitting is adapted to perform several functions related to, for example, transmitting information (e.g., data) to another device and / or programming (e.g., storage medium 4604). The code 4642) for transmission stored in the Initially, the circuit / module 4622 for transmitting obtains information to be transmitted (eg, from the memory device 4608, the circuit / module 4620 for generating, or some other component). In various implementations, the information to be transmitted may include satellite and cell transition information to be transmitted to the user terminal. In various implementations, the information to be transmitted may include information indicating a measurement gap. The circuit / module for transmitting 4622 may then format the information for transmission (eg, in a message, according to the protocol, etc.). The circuit / module 4622 for transmitting then causes the information to be transmitted via a wireless communication medium (eg, via satellite signaling). For this purpose, the sending circuit / module 4622 may send data to a communication interface 4602 (eg, a digital subsystem or an RF subsystem) or some other component for transmission. In some implementations, the communication interface 4602 includes circuitry / module 4622 for transmitting and / or code 4642 for transmitting.

  A circuit / module 4624 for performing handoff is a circuit and / or adapted to perform several functions related to performing handoff for user terminals to different cells and at least one satellite, for example. Programming (eg, code 4644 for performing handoffs stored on storage medium 4604) may be included. In some implementations, the circuit / module 4624 for performing handoff identifies a target satellite and / or target cell based on satellite and cell transition information (eg, Table 1). For this purpose, the circuit / module 4624 for performing the handoff collects this information, processes this information to identify the target, and sets the communication parameters to allow communication with the user terminal through the target. Reconfigure. For example, for a given location of a user terminal, a circuit / module 4624 for performing a handoff is based on the location of the satellite and the direction and coverage of the satellite cell over time. Can provide sufficient coverage for the user terminal. If the satellite / cell provides sufficient coverage, the circuit / module 4624 for performing the handoff can designate that satellite / cell as the target for the handoff and initiate handoff signaling accordingly.

  A circuit / module 4626 for receiving is adapted to perform some functions related to receiving information (e.g., data) from another device, for example, and / or programming (e.g., storage medium 4604). A code 4646) for receiving stored. In various implementations, the information to be received may include a measurement message from the user terminal. In various implementations, the information to be received may include capability information from the user terminal. In various implementations, the information to be received may include a message from the user terminal. Initially, the receiving circuit / module 4626 obtains the received information. For example, a circuit / module 4626 for receiving from a component of apparatus 4600 (e.g., communication interface 4602 (e.g., digital subsystem or RF subsystem), memory device 4608, or some other component) or user This information can be obtained directly from the device (eg, satellite) that relayed the information from the terminal. In some implementations, the receiving circuit / module 4626 identifies the memory location of the value in the memory device 4608 and invokes the reading of that location. In some implementations, the receiving circuit / module 4626 processes (eg, decodes) the received information. The circuit / module 4626 for receiving outputs the received information (eg, stores the received information in the memory device 4608 or transmits the information to another component of the apparatus 4600). In some implementations, the communication interface 4602 includes circuitry / module 4626 for receiving and / or code 4642 for receiving.

  A circuit / module 4628 for determining whether to modify is adapted to perform several functions related to determining whether to modify satellite and cell transition information, for example, and / or programming ( For example, code 4648) for determining whether to modify stored in storage medium 4604 may be included. In some implementations, the circuit / module 4628 for deciding whether to modify makes this decision based on the received measurement message. For this purpose, the circuit / module 4628 for determining whether to modify this measurement message information (e.g. from the circuit / module 4626 for receiving, the memory device 4608, or some other component of the apparatus 4600) To collect. The circuit / module 4628 for determining whether to correct then processes this information to determine whether the current timing parameters need to be changed (e.g., due to bad RF conditions or improved RF conditions). Can be determined. For example, the circuit / module 4628 for determining whether to modify may compare the signal quality information included in the measurement message with one or more signal quality thresholds. Finally, the circuit / module 4628 for deciding whether to modify generates an indication of this decision (eg, indicating that the handoff is accelerated or delayed).

  A circuit / module 4630 for selecting is adapted to perform several functions related to, for example, selecting a handoff procedure for a user terminal and / or programming (e.g., stored in storage medium 4604). A code 4650) for selection. In some implementations, the circuit / module for selecting 4630 makes this determination based on capability information received from the user terminal. For this purpose, the circuit / module 4630 for selection collects this capability information and processes this information to identify the handoff procedure and generate an indication of this decision. For example, the selection of the handoff procedure may determine whether the user terminal is double sensitive and enable monitoring of measurement messages from the user terminal based on whether the user terminal is double sensitive. Can be accompanied by invalidation. Accordingly, in some implementations, the circuit / module 4630 for selecting obtains configuration information about the user terminal (e.g., from the memory device 4608, from the receiver 4616, or from some other component) Review this information to identify the user terminal's ability to select a supported handoff procedure and indicate this decision (e.g., memory device 4608, circuit / module 4624 to perform the handoff, or some other To be sent to the component).

  Circuit / module 4632 for determining time may be, for example, circuitry and / or programming (e.g., stored in storage medium 4604) adapted to perform several functions related to determining user terminal handoff time. May include code 4562) for determining the time being. In some implementations, the circuit / module for determining time 4632 makes this determination based on satellite and cell transition information (eg, Table 1). For this purpose, the circuit / module 4632 for determining time obtains this information (eg, from the circuit / module 4626 for receiving, the memory device 4608, or some other component of the apparatus 4600). Circuit / module 4632 for determining the time may then process this information to determine the next handoff time (eg, frame number) of the user terminal. For example, the circuit / module 4632 for determining time may compare the current time indication (eg, frame number) with the timing indication in Table 1. The circuit / module 4632 for determining the time generates an instruction for this determination (e.g. indicating the time of the handoff), and this instruction is a component of the device 4600 (e.g. the circuit / module 4634 for transferring, the memory Device 4608, or some other component).

  Circuits / modules 4634 for transfer may be circuitry and / or programming (e.g., stored in storage medium 4604) adapted to perform some functions related to transferring user queues prior to handoff, for example. A code 4654) for transmission. Initially, the circuit / module 4634 for transferring receives an indication of the time of handoff (eg, from the memory device 4608, the circuit / module 4632 for determining time, or some other component). Next, prior to the time of the handoff, the circuit / module 4634 for transferring obtains the queue information to be transmitted (eg, from the memory device 4608, or some other component). In various implementations, this information may be sent to another GN. The circuit / module 4634 for forwarding may then format the queue information for transmission (eg, in a message, according to the protocol, etc.). The circuit / module 4634 for forwarding then causes the queue information to be transmitted via an appropriate communication medium (eg, via the infrastructure 106 of FIG. 1). For this purpose, the circuit / module 4634 for transferring may send the data to the communication interface 4602 or some other component for transmission. In some implementations, the communication interface 4602 includes circuitry / modules 4634 for transfer and / or code 4654 for transfer.

  A circuit / module 4636 for determining a measurement gap is a circuit and / or programming (e.g., memory) adapted to perform several functions related to, for example, determining a measurement gap for measuring a satellite signal. A code 4656) for determining a measurement gap stored on the medium 4604 may be included. In some implementations, the circuit / module 4636 for determining the measurement gap determines that there may be a satellite indication error that forces the handoff time to change. As a result of this determination or some other trigger, the circuit / module 4636 for determining the measurement gap should be used by the UT (e.g. a measurement gap pattern indicating the time when the GN is not transmitting to the UT) Generate instructions for The circuit / module 4636 for determining the measurement gap then transmits this indication to a component of the device 4600 (eg, circuit / module 4622 for transmission, memory device 4608, or some other component).

  Circuit / module 4638 for determining that a measurement gap is not required is a circuit adapted to perform several functions related to determining that a measurement gap for measuring satellite signals is not required, for example. And / or programming (eg, code 4658 for determining that a measurement gap stored in storage medium 4604 is not needed). In some implementations, a circuit / module 4638 for determining that a measurement gap is not necessary obtains information regarding the status of one or more satellites. Based on this information, the circuit / module 4638 for determining that no measurement gap is required determines that there are no satellite indication errors that force a change in handoff time. As a result of this determination or some other trigger, a circuit / module 4638 for determining that a measurement gap is not required generates an instruction for this determination and this instruction is generated by a component of the device 4600 (e.g., to generate Circuit / module 4620, memory device 4608, or some other component).

  As described above, programming stored by storage medium 4604, when executed by processing circuit 4610, causes processing circuit 4610 to have one of the various functions and / or processing operations described herein. Or run multiple. For example, once programming is performed by the processing circuit 4610, the processing circuit 4610 may be in various implementations shown in FIGS. 11, 12, 15-24, 27, 29, 31-33, FIG. One or more of the various functions, steps, and / or processes described herein with respect to 35, 37, 47, and 48 may be performed. As shown in FIG. 46, storage medium 4604 determines code 4640 to generate, code 4642 to transmit, code 4644 to perform handoff, code 4646 to receive, and whether to modify. Code 4648 for selecting, code 4650 for selecting, code 4651 for determining the time, code 4654 for transferring, code 4656 for determining the measurement gap, or for determining that no measurement gap is required One or more of the codes 4658 may be included.

Sixth Exemplary Process FIG. 47 illustrates a process 4700 for communication according to some aspects of the present disclosure. Process 4700 may be performed within a processing circuit (eg, processing circuit 4610 of FIG. 46) that may be located in the GN or some other suitable device. In some implementations, process 4700 may be performed by a GN for at least one non-geostationary satellite. In some implementations, process 4700 represents the operations performed by GN controller 250 of FIG. Of course, in various aspects within the scope of this disclosure, process 4700 may be performed by any suitable apparatus capable of supporting communication operations.

  At block 4702, a device (eg, GN) generates satellite handoff information that specifies a handoff time for a particular cell of a particular satellite. In some aspects, the operation of block 4702 may correspond to the operation of block 2406 of FIG.

  In some aspects, the generation of satellite handoff information may be based on at least one of user terminal capability information or user terminal location information. In some aspects, the capability information may indicate at least one of whether the user terminal can sense multiple beams or whether the user terminal can sense multiple satellites. In some aspects, the capability information may indicate at least one of an inter-beam tuning time for the user terminal or an inter-satellite tuning time for the user terminal. In some aspects, the location information may include at least one of a current location of the user terminal or a motion vector of the user terminal.

  In some aspects, the generation of satellite handoff information may be based on at least one of ephemeris information, constraints due to a running system, or satellite indication errors. In some aspects, generation of satellite handoff information may be triggered based on at least one of a user terminal handoff to a different satellite or receipt of a measurement message from the user terminal.

  In some implementations, the generating circuit / module 4620 of FIG. 46 performs the operations of block 4702. In some implementations, the generating code 4640 of FIG. 46 is executed to perform the operations of block 4702.

  In block 4704, the device transmits satellite handoff information to the user terminal. In some aspects, this information is transmitted via a satellite. In some aspects, the operation of block 4704 may correspond to the operation of block 2408 of FIG.

  The satellite handoff information may take various forms as taught herein. In some aspects, the satellite handoff information may include a table that includes handoff activation times. In some aspects, satellite handoff information may include at least one detuning time. In some aspects, the handoff information may be for at least one future handoff (eg, a next handoff, a later handoff, or some other handoff that occurs in the future). In some aspects, the handoff information may be for a next beam handoff and occurs at least one future satellite handoff (e.g., a next handoff and some other subsequent handoff). May be for the next two handoffs).

  In some implementations, the transmitting circuit / module 4622 of FIG. 46 performs the operations of block 4704. In some implementations, the transmit code 4642 of FIG. 46 is executed to perform the operations of block 4704.

  In some aspects, the process 4700 may further include performing a handoff for the user terminal to the different beams and at least one satellite based on the satellite handoff information. This handoff may involve a change of at least one of a satellite access network (SAN) or a GN antenna. This handoff may involve changing at least one of a satellite beam or a forward service link (FSL) frequency. In some aspects, these operations may correspond to the operations of block 2410 of FIG. In some implementations, the circuit / module 4624 for performing the handoff of FIG. 46 performs these operations. In some implementations, code 4644 for performing the handoff of FIG. 46 is executed to perform these operations.

  In some aspects, the process 4700 may further include receiving a measurement message from the user terminal and determining whether to modify satellite handoff information based on the measurement message. The modification of the satellite handoff information may include advancing the handoff timing or delaying the handoff timing. In some aspects, these operations may correspond to the operations of block 3102 and block 3104 of FIG. In some implementations, the receive circuit / module 4626 of FIG. 46 performs the receive operation. In some implementations, the receive code 4646 of FIG. 46 is executed to perform a receive operation. In some implementations, the circuit / module 4628 for determining whether to modify in FIG. 46 performs the decision operation. In some implementations, the code 4648 for determining whether to modify in FIG. 46 is executed to perform the decision operation.

  In some aspects, the process 4700 may further include determining a measurement gap for measuring the satellite signal and transmitting information indicating the measurement gap to the user terminal, wherein the measurement message is the measurement message. Including instructions for measurement of signals from at least one satellite performed during the gap. In some aspects, these operations may correspond to the operations of block 3506 and block 3508 of FIG. In some implementations, the circuit / module 4636 for determining the measurement gap of FIG. 46 performs the determining operation. In some implementations, the code 4656 for determining the measurement gap of FIG. 46 is executed to perform the determination operation. In some implementations, the transmit circuit / module 4622 of FIG. 46 performs the transmit operation. In some implementations, the code for transmission 4642 of FIG. 46 is executed to perform a transmission operation.

  In some aspects, the process 4700 may further include receiving capability information from the user terminal and selecting a handoff procedure for the user terminal based on the received capability information. The capability information may indicate whether the user terminal is double sensitive. Selection of the handoff procedure may include enabling or disabling monitoring of measurement messages from the user terminal based on whether the user terminal is double-sensitive. In some aspects, these operations may correspond to the operations of block 2702 and block 2706 of FIG. In some implementations, the receive circuit / module 4626 of FIG. 46 performs the receive operation. In some implementations, the receive code 4646 of FIG. 46 is executed to perform a receive operation. In some implementations, the selection circuit / module 4630 of FIG. 46 performs the selection operation. In some implementations, the selection code 4650 of FIG. 46 is executed to perform a selection operation.

  In some aspects, the process 4700 may further include determining a time for user terminal handoff and transferring at least one user queue prior to handoff. In some aspects, these operations may correspond to the operations of block 3702 and block 3704 of FIG. In some implementations, the circuit / module 4632 for determining the time of FIG. 46 performs the determination operation. In some implementations, the code 4652 for determining the time of FIG. 46 is executed to perform the determination operation. In some implementations, the transfer circuit / module 4634 of FIG. 46 performs the transfer operation. In some implementations, the forwarding code 4654 of FIG. 46 is executed to perform a transmission operation.

  In some aspects, the process 4700 may further include receiving a message comprising at least one of user terminal paging area information or user terminal location information from the user terminal. In some aspects, these operations may correspond to the operations of block 2902 of FIG. In some implementations, the receive circuit / module 4626 of FIG. 46 performs these operations. In some implementations, the receiving code 4646 of FIG. 46 is executed to perform these operations.

  In some aspects, the process 4700 may further include determining that a measurement gap for measuring satellite signals is not required, as a result of this determination, generating satellite handoff information Is accompanied by not including detuning time. In some aspects, these operations may correspond to the operations of block 3502 and block 3504 of FIG. In some implementations, the circuit / module 4638 for determining that the measurement gap of FIG. 46 is not necessary performs these operations. In some implementations, code 4658 for determining that the measurement gap of FIG. 46 is not needed is executed to perform these operations.

Seventh Exemplary Process FIG. 48 illustrates a process 4800 for communication according to some aspects of the present disclosure. Process 4800 may be performed within a processing circuit (eg, processing circuit 4610 of FIG. 46) that may be located in the GN or some other suitable device. In some implementations, process 4800 may be performed by a GN for at least one non-geostationary satellite. In some implementations, process 4800 represents the operations performed by GN controller 250 of FIG. Of course, in various aspects within the scope of this disclosure, process 4800 may be performed by any suitable apparatus capable of supporting communication operations.

  In block 4802, a device (eg, GN) generates satellite and cell transition information that specifies when to start and end communication with a particular cell of a particular satellite. In some aspects, the operation of block 4802 may correspond to the operation of block 2406 of FIG.

  In some aspects, satellite and cell transition information is generated based on at least one of user terminal capability information, user terminal location information, ephemeris information, or constraints due to a running system. . In some aspects, the capability information may indicate whether the user terminal can sense multiple cells, whether the user terminal can sense multiple satellites, inter-cell tuning time for the user terminal, or for the user terminal. Indicates at least one of the inter-satellite tuning times. In some aspects, the location information includes a current location of the user terminal or a motion vector of the user terminal.

  In some aspects, generation of satellite and cell transition information may be triggered based on at least one of a user terminal handoff to a different satellite or reception of a measurement message from the user terminal.

  In some implementations, the circuit / module for generating 4620 of FIG. 46 performs the operations of block 4802. In some implementations, the generating code 4640 of FIG. 46 is executed to perform the operations of block 4802.

  In block 4804, the apparatus transmits satellite and cell transition information to the user terminal. In some aspects, this information is transmitted via a satellite. In some aspects, the operation of block 4804 may correspond to the operation of block 2408 of FIG.

  In some implementations, the transmitting circuit / module 4622 of FIG. 46 performs the operations of block 4804. In some implementations, the transmit code 4642 of FIG. 46 is executed to perform the operations of block 4804.

  In some aspects, the process 4800 further includes performing a handoff for the user terminal to a different cell and at least one satellite based on the satellite and cell transition information. In some aspects, these operations may correspond to the operations of block 2410 of FIG. In some implementations, the circuit / module 4624 for performing the handoff of FIG. 46 performs these operations. In some implementations, code 4644 for performing the handoff of FIG. 46 is executed to perform these operations.

  In some aspects, the process 4800 may further include receiving a measurement message from the user terminal and determining whether to modify satellite and cell transition information based on the measurement message. In some aspects, modification of satellite and cell transition information includes speeding up handoff or delaying handoff. In some aspects, these operations may correspond to the operations of block 3102 and block 3104 of FIG. In some implementations, the circuit / module 4626 for receiving and / or the circuit / module 4628 for deciding whether to perform these operations of FIG. 46 perform these operations. In some implementations, the code 4646 for receiving of FIG. 46 and / or code 4648 for determining whether to modify is executed to perform these operations.

  In some aspects, the process 4800 further includes selecting a handoff procedure for the user terminal based on the capability information received from the user terminal. In some aspects, the selection of the handoff procedure includes enabling or disabling monitoring of measurement messages from the user terminal based on whether the user terminal is dual sensitive. In some aspects, these operations may correspond to the operations of block 2706 of FIG. In some implementations, the selection circuit / module 4630 of FIG. 46 performs these operations. In some implementations, the selection code 4650 of FIG. 46 is executed to perform these operations.

  In some aspects, the process 4800 further includes determining a user terminal handoff time and transferring a user queue prior to the handoff. In some implementations, the circuit / module 4632 for determining time and / or the circuit / module 4634 for transferring perform these operations in FIG. In some implementations, the code 4562 for determining time and / or the code 4654 for transferring in FIG. 46 are executed to perform these operations.

Fourth Exemplary Device FIG. 49 shows a block diagram of an exemplary hardware implementation of another device 4900 configured to communicate according to one or more aspects of the present disclosure. For example, apparatus 4900 may be embodied or implemented in a UT or any other type of device that supports wireless communication. Thus, in some aspects, device 4900 may be an example of UT400 or UT401 of FIG. In various implementations, the device 4900 may be embodied in a mobile phone, smartphone, tablet, portable computer, server, personal computer, sensor, entertainment device, vehicle part, medical device, or any other electronic device having circuitry. Or may be implemented.

  Apparatus 4900 includes a communication interface (e.g., at least one transceiver) 4902, a storage medium 4904, a user interface 4906, a memory device 4908 (e.g., that stores satellite-related information 4918), and processing circuitry (e.g., at least one processor). ) 4910 included. In various implementations, the user interface 4906 is one of a keypad, display, speaker, microphone, touch screen display, or one of several other circuits for receiving input from or sending output to the user. Or a plurality may be included. Communication interface 4902 may be coupled to one or more antennas 4912 and may include a transmitter 4914 and a receiver 4916. In general, the components of FIG. 49 may be similar to the corresponding components of apparatus 4600 of FIG.

  In accordance with one or more aspects of the present disclosure, processing circuit 4910 is any of features, processes, functions, operations, and / or routines for any or all of the devices described herein. Or it can be adapted to do everything. For example, the processing circuit 4910 relates to FIGS. 11, 12, 15 to 23, 25, 26, 28, 30, 30, 32 to 34, 36, 38, 50, and 51. It may be configured to perform one or more of the described steps, functions, and / or processes. As used herein, the term “adapted” with respect to processing circuit 4910 means that processing circuit 4910 performs certain processes, functions, operations, and / or routines in accordance with various features described herein. One or more of being configured to be used, so utilized, so implemented, and / or so programmed.

  The processing circuit 4910 is described with respect to FIGS. 11, 12, 15-23, 25, 26, 28, 30, 32-34, 36, 38, 50, and 51. It may be a special processor, such as an application specific integrated circuit (ASIC) that functions as a means (eg, a structure therefor) for performing one or more of the operations described above. The processing circuit 4910 functions as an example of a means for transmitting and / or a means for receiving. In various implementations, the processing circuit 4910 may incorporate the functionality of the control processor 420 of FIG.

  According to at least one example of apparatus 4900, processing circuit 4910 includes a circuit / module 4920 for receiving, a circuit / module 4922 for performing a handoff, a circuit / module 4924 for measuring a signal, and for transmitting. Circuit / module 4926, circuit / module 4928 for determining whether to transmit, or circuit / module 4930 for performing a random access procedure. In various implementations, circuits / modules 4920 for receiving, circuits / modules 4922 for performing handoffs, circuits / modules 4924 for measuring signals, circuits / modules 4926 for transmitting, whether to transmit The circuit / module 4928 for determining and the circuit / module 4930 for performing the random access procedure may correspond at least in part to the control processor 420 of FIG.

  Circuits / modules 4920 for receiving are adapted to perform some functions related to receiving information (eg, data) from another device, for example, and / or programming (eg, storage medium 4904 May include a code 4932) for receiving. In various implementations, the information to be received may include satellite and cell transition information that specifies when to start and end communication with a particular cell of a particular satellite. In various implementations, the information to be received may include information indicating a measurement gap. In various implementations, the information to be received may include a dedicated preamble signature. Initially, the receiving circuit / module 4920 obtains the received information. For example, circuit / module 4920 for receiving may obtain this information directly from a component of apparatus 4900 or directly from a device (eg, satellite) that relayed information from the GN. In the former case, the circuit / module 4920 for receiving this information from the communication interface 4902 (e.g., a UT transceiver as described above for UT 400 in FIG. 4), memory device 4908, or some other component. You can get. In some implementations, the circuit / module 4920 for receiving identifies a memory location of the value in the memory device 4908 and invokes reading that location. In some implementations, the circuit / module 4920 for receiving processes (eg, decodes) the received information. Circuit / module 4920 for receiving outputs the received information (e.g., received information, memory device 4908, circuit / module 4922 for performing handoff, or some other component of apparatus 4900) To send). In some implementations, the communication interface 4902 includes circuitry / module 4920 for receiving and / or code 4932 for receiving.

  Circuits / modules 4922 for performing handoffs are adapted to perform some functions related to performing handoffs to a particular cell of a particular satellite, for example, and / or programming (e.g., memory Code 4934) for performing a handoff stored on media 4904 may be included. In some implementations, the circuit / module 4922 for performing handoff identifies a particular cell of a particular satellite based on satellite and cell transition information (eg, Table 1). For this purpose, the circuit / module 4922 for performing the handoff collects this information, processes this information to identify the satellite and cell, and communicates with the GN via the identified satellite and cell. Reconfigure the communication parameters so that For example, at a particular point in time, the circuit / module 4922 for performing the handoff uses the information in Table 1 to determine whether the user terminal should switch to a different satellite cell. Can do. As another example, a trigger may be prepared at the cell / satellite transition times (eg, frame numbers) shown in Table 1.

  Circuits / modules 4924 for measuring signals are adapted to perform several functions related to, for example, receiving and processing signals from at least one satellite (e.g., storage media) A code 4936) for measuring a signal stored in 4904 may be included. Initially, a circuit / module 4924 for measuring the signal receives the signal. For example, a circuit / module 4924 for measuring a signal may obtain signal information from a component of the device 4900 or directly from the satellite that transmitted the signal. As an example of the former case, a circuit / module 4924 for measuring a signal includes a communication interface 4902 (e.g., a UT transceiver as described above for UT400 in FIG. 4), a memory device 4908 (e.g., received) Signal information may be obtained if the signal is digitized) or from some other component of the device 4900. A circuit / module 4924 for measuring the signal then processes the received signal (eg, to determine at least one signal quality of the signal). Finally, the circuit / module 4924 for measuring the signal generates an indication of this measurement and this indication is sent to the memory device 4908, the circuit / module 4924 for transmitting, or some other component of the apparatus 4900. Send. In some implementations, the communication interface 4902 includes a circuit / module 4924 for measuring signals and / or code 4936 for measuring signals.

  A circuit / module 4926 for transmitting is adapted to perform several functions related to, for example, transmitting information (e.g., a message) to another device and / or programming (e.g., storage medium 4904). A code 4938) for transmission stored in Initially, circuit / module 4926 for transmitting obtains information to be transmitted (eg, from memory device 4908, circuit / module 4924 for measuring signals, or some other component). In various implementations, the information to be transmitted may include a measurement message based on a measured signal, a message that includes user terminal capability information, or a message that includes user terminal location information. In various implementations, the information to be transmitted may include a message that includes user terminal capability information. In various implementations, the information to be transmitted may include a message that includes user terminal location information. In various implementations, the information to be transmitted may include a message that includes user terminal paging area information. A circuit / module 4926 for transmitting may format the information for transmission (eg, according to a message format, according to a protocol, etc.). Circuit / module 4926 for transmitting then causes the information to be transmitted via a wireless communication medium (eg, via satellite signaling). For this purpose, the circuit / module 4926 for transmitting transmits data to a communication interface 4902 (e.g., a UT transceiver as described above for UT 400 in FIG. 4) or some other component for transmission. Can do. In some implementations, the communication interface 4902 includes circuitry / module 4926 for transmitting and / or code 4938 for transmitting.

  A circuit / module 4928 for determining whether to transmit is adapted to perform some function related to determining whether to transmit a message, for example, and / or programming (e.g., storage medium Code 4940) for determining whether to transmit stored in 4904 may be included. In some implementations, the information to be transmitted may include a measurement message based on the signal being measured. Initially, a circuit / module 4928 for determining whether to transmit is to make a transmission decision (e.g., from a memory device 4908, a circuit / module 4924 for measuring a signal, or some other component) Get information used for. For example, circuit / module 4928 for determining whether to transmit may obtain signal quality information from circuit / module 4924 for measuring the signal. In this case, the circuit / module 4928 for deciding whether to transmit determines whether the signal from the current serving satellite and / or the signal from the target satellite is inappropriate (e.g. signal quality information Can be determined by comparing to a threshold). For example, transmission of a measurement message can be triggered when the signal is inappropriate. Finally, the circuit / module 4928 for deciding whether to transmit generates an instruction for this decision, and this instruction is sent to the memory device 4908, the circuit / module 4926 for transmitting, or some other device 4900. Send to component.

  A circuit / module 4930 for performing a random access procedure is adapted to perform several functions related to performing a non-contention based random access procedure, for example, using a dedicated preamble signature And / or programming (eg, code 4942 for performing random access procedures stored on storage medium 4904). In some implementations, the circuit / module 4930 for performing the random access procedure performs the random access operation described above with respect to FIG. In some implementations, the circuit / module 4930 for performing the random access procedure performs the random access operation described above with respect to FIG. In some implementations, the circuit / module 4930 for performing the random access procedure performs the random access operation described above with respect to FIG. In some implementations, the circuit / module 4930 for performing the random access procedure performs the random access operation described above with respect to FIG. In some implementations, the circuit / module 4930 for performing the random access procedure performs the operations described above with respect to FIG.

  As described above, programming stored by storage medium 4904, when executed by processing circuit 4910, causes processing circuit 4910 to perform one of the various functions and / or processing operations described herein. Or run multiple. For example, once programming is performed by the processing circuit 4910, the processing circuit 4910 may be configured in various implementations in FIGS. 11, 12, 15-23, 25, 26, 28, 30, 30, FIG. One or more of the various functions, steps, and / or processes described herein with respect to 32-34, 36, 38, 50, and 51 may be performed. As shown in FIG. 49, storage medium 4904 has code 4932 for receiving, code 4934 for performing handoff, code 4936 for measuring signal, code 4938 for transmitting, determining whether to transmit One or more of code 4940 for performing or code 4942 for performing a random access procedure may be included.

Eighth Exemplary Process FIG. 50 illustrates a process 5000 for communication according to some aspects of the present disclosure. Process 5000 may be performed within a processing circuit (eg, processing circuit 4910 of FIG. 49) that may be located in the UT or some other suitable device. In some implementations, process 5000 represents the operations performed by control processor 420 of FIG. Of course, in various aspects within the scope of this disclosure, process 5000 may be performed by any suitable apparatus capable of supporting communication operations.

  At block 5002, an apparatus (eg, UT) receives satellite handoff information that specifies a handoff time for a particular cell of a particular satellite. In some aspects, the operation of block 5002 may correspond to the operation of block 2504 of FIG.

  The satellite handoff information may take various forms as taught herein. In some aspects, the satellite handoff information may include a table that includes handoff activation times. In some aspects, satellite handoff information may include at least one detuning time. In some aspects, handoff information may be defined based in part on satellite indication error. In some aspects, the handoff information may be for at least one future handoff (eg, a next handoff, a later handoff, or some other handoff that occurs in the future). In some aspects, the handoff information may be for a next beam handoff and occurs at least one future satellite handoff (e.g., a next handoff and some other subsequent handoff). May be for the next two handoffs).

  In some implementations, the receiving circuit / module 4920 of FIG. 49 performs the operations of block 5002. In some implementations, the receiving code 4932 of FIG. 49 is executed to perform the operations of block 5002.

  In block 5004, the device performs a handoff to a particular cell for a particular satellite based on the satellite handoff information. In some aspects, the operation of block 5004 may correspond to the operation of block 2506 of FIG.

  In some aspects, this handoff may involve a change in at least one of a satellite access network (SAN), a GN antenna, a satellite beam, or a forward service link (FSL) frequency.

  In some implementations, a circuit / module 4922 for performing the handoff of FIG. 49 performs the operations of block 5004. In some implementations, the code 4934 for performing the handoff of FIG. 49 is executed to perform the operations of block 5004.

  In some aspects, the process 5000 may further include measuring a signal from at least one satellite and transmitting a measurement message based on the measured signal, where the satellite handoff information is measured Received as a result of the message being sent. The measurement message may include at least one of measurement data based on the measured signal, a request to advance handoff timing, or a request to delay handoff timing. In some aspects, these operations may correspond to the operations of block 3004 and block 3008 of FIG.

  In some aspects, the process 5000 may further include receiving information indicating a measurement gap for measuring the satellite signal, and the measurement of the signal from the at least one satellite is performed during the measurement gap. . In some aspects, these operations may correspond to the operations of block 3602 and block 3604 of FIG.

  In some aspects, the process 5000 further includes a measurement message based on at least one of whether the signal from the current serving satellite is inappropriate or whether the signal from the target satellite is inappropriate. The step of determining whether to transmit may be included. In some aspects, these operations may correspond to the operations of block 3006 of FIG.

  In some aspects, the process 5000 may further include transmitting a message that includes user terminal capability information, wherein the received satellite handoff information is based on the user terminal capability information. The user terminal capability information includes at least one of whether the user terminal can sense a plurality of beams, whether the user terminal can sense a plurality of satellites, a user terminal's inter-beam tuning time, or a user terminal's inter-satellite tuning time. One can be shown. The transmission of a message containing user terminal capability information can be triggered as a result of the initial connection to the satellite. In some aspects, these operations may correspond to the operations of block 2606 of FIG.

  In some aspects, the process 5000 may further include transmitting a message that includes user terminal location information, wherein the received satellite handoff information is based on the user terminal location information. The user terminal position information may include at least one of a current user terminal position or a user terminal motion vector. The transmission of a message containing user terminal location information may be triggered as at least one result of an initial connection to the satellite, whether the user terminal exceeds a geographical boundary, or whether an error limit has been exceeded. In some aspects, these operations may correspond to the operations of block 2806 of FIG.

  In some aspects, process 5000 may further include receiving a dedicated preamble signature and performing a non-contention based random access procedure using the dedicated preamble signature. In some aspects, these operations may correspond to the operations of block 3802 and block 3804 of FIG.

  In some aspects, the process 5000 further includes a measurement message based on at least one of whether the signal from the current serving satellite is inappropriate or whether the signal from the target satellite is inappropriate. The step of determining whether to transmit may be included. In some aspects, these operations may correspond to the operations of block 2806 of FIG.

Ninth Exemplary Process FIG. 51 illustrates a process 5100 for communication according to some aspects of the present disclosure. Process 5100 may be performed within a processing circuit (eg, processing circuit 4910 of FIG. 49) that may be located in the UT or some other suitable device. In some implementations, process 5100 represents the operations performed by control processor 420 of FIG. Of course, in various aspects within the scope of this disclosure, process 5100 may be performed by any suitable apparatus capable of supporting communication operations.

  In block 5102, an apparatus (eg, UT) receives satellite and cell transition information specifying a time to start and end communication with a particular cell of a particular satellite. In some aspects, the operation of block 5102 may correspond to the operation of block 2504 of FIG.

  In some implementations, the receiving circuit / module 4920 of FIG. 49 performs the operations of block 5102. In some implementations, the receiving code 4932 of FIG. 49 is executed to perform the operations of block 5102.

  In block 5104, the device performs a handoff of a particular satellite to a particular cell based on the satellite and cell transition information. In some aspects, the operation of block 5104 may correspond to the operation of block 2506 of FIG.

  In some implementations, a circuit / module 4922 for performing the handoff of FIG. 49 performs the operations of block 5104. In some implementations, the code 4934 for performing the handoff of FIG. 49 is executed to perform the operations of block 5104.

  In some aspects, the process 5100 further includes measuring a signal from at least one satellite and transmitting a measurement message based on the measured signal, wherein the satellite and cell transition information is the measurement message. Is received as a result of sending. In some aspects, the measurement message includes at least one of measurement data, a request to advance handoff timing, or a request to delay handoff timing. In some aspects, the process 5100 further includes a measurement message based on at least one of whether the signal from the current serving satellite is inappropriate or whether the signal from the target satellite is inappropriate. Determining whether to transmit. In some aspects, these operations may correspond to the operations of blocks 3004-3008 of FIG. In some implementations, the circuit / module 4924 for measuring the signals of FIG. 49 and / or the circuit / module 4928 for determining whether to transmit perform these operations. In some implementations, code 4936 for measuring the signal of FIG. 49 and / or code 4940 for determining whether to transmit is executed to perform these operations.

  In some aspects, the process 5100 further includes transmitting a message including user terminal capability information, wherein the satellite and cell transition information is based on the user terminal capability information. In some aspects, the user terminal capability information may indicate whether the user terminal can sense multiple cells, whether the user terminal can sense multiple satellites, inter-cell tuning time of the user terminal, or between satellites of the user terminal. Indicates at least one of the tuning times. In some aspects, transmission of a message that includes user terminal capability information is triggered as a result of an initial connection to the satellite. In some aspects, these operations may correspond to the operations of blocks 2602-2606 in FIG. In some implementations, the transmit circuit / module 4926 of FIG. 49 performs these operations. In some implementations, the sending code 4938 of FIG. 49 is executed to perform these operations.

  In some aspects, the process 5100 further includes transmitting a message that includes user terminal location information, wherein the satellite and cell transition information is based on the user terminal location information. In some aspects, the user terminal location information includes a current user terminal location or a user terminal motion vector. In some aspects, the transmission of the message including the user terminal location information is as a result of at least one of an initial connection to the satellite, whether the user terminal exceeds a geographic boundary, or exceeds an error limit. Triggered. In some aspects, these operations may correspond to the operations of blocks 2802-2806 of FIG. In some implementations, the transmit circuit / module 4926 of FIG. 49 performs these operations. In some implementations, the sending code 4938 of FIG. 49 is executed to perform these operations.

Additional Embodiments The examples described herein are provided to illustrate some concepts of the present disclosure. Those skilled in the art will appreciate that these are merely exemplary in nature and that other examples may fall within the scope of the disclosure and the appended claims. Based on the teachings herein, the aspects disclosed herein may be implemented independently of any other aspects, and two or more of these aspects may be combined in various ways. It should be understood by those skilled in the art. For example, an apparatus may be implemented or a method may be practiced using any number of aspects described herein. In addition, such devices may be implemented in addition to one or more of the aspects described herein, or using other structures, functions, or structures and functions. Well, or such a method may be practiced.

  As those skilled in the art will readily appreciate, the various aspects described throughout this disclosure can be extended to any suitable telecommunications system, network architecture, and communication standard. By way of example, various aspects may be applied to wide area networks, peer to peer networks, local area networks, other suitable systems, or any combination thereof, including those described by standards not yet defined. .

  Many aspects are described in terms of a series of activities that may be performed, for example, by elements of a computing device. The various activities described herein are specific circuits 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. May be executed by an array (FPGA), or various other types of general purpose or special purpose processors or circuits, may be executed by program instructions executed by one or more processors, or both It will be appreciated that some combinations may be performed. In addition, these series of activities described herein may be performed in any form that stores a corresponding set of computer instructions that, when executed, cause an associated processor to perform the functions described herein. It can be considered to be fully embodied in a computer-readable storage medium. Thus, various aspects of the disclosure may be embodied in a number of different forms, all considered to be within the scope of the claimed subject matter. Further, for each aspect described herein, the corresponding form of any such aspect is described herein as, for example, "logic configured to" perform the operations described. Sometimes.

  Those skilled in the art will understand 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 that may be referred to throughout the above description are voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any of them It can be expressed by a combination.

  Further, those skilled in the art will recognize that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with aspects disclosed herein are electronic hardware, computer software, or a combination of both. It will be understood that can be implemented as: To clearly illustrate this interchangeability between hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functions are implemented as hardware or software depends on specific application examples and design constraints imposed on the entire system. Those skilled in the art can implement the described functions in a variety of ways for each specific application, but such implementation decisions should be construed to cause deviations from the scope of the present disclosure. is not.

  One or more of the components, steps, features, and / or functions shown above may be reconfigured and / or combined as a single component, step, feature, or function. Or may be embodied in several components, steps or functions. Additional elements, components, steps, and / or functions may be added without departing from the novel features disclosed herein. The apparatus, devices, and / or components shown above may be configured to perform one or more of the methods, features, or steps described herein. Also, the novel algorithms described herein may be efficiently implemented in software and / or incorporated into hardware.

  It should be understood that the specific order or hierarchy of steps in the methods disclosed is an illustration of exemplary processes. It is understood that a specific order or hierarchy of steps in the method may be reconfigured based on design preferences. The accompanying method claims present elements of the various steps in a sample order, and are intended to be limited to the specific order or hierarchy presented unless specifically stated in the claims. Not what you want.

  The methods, sequences or algorithms described with respect to the aspects disclosed herein may be implemented directly in hardware, in software modules executed by a processor, or in a combination of the two. Software modules reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art Can do. An example storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.

  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 “aspect” does not require that all aspects include the discussed features, advantages, or modes of operation.

  The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms `` comprises, comprising '' or `` includes, including '' as used herein, describe the presence of the stated feature, integer, step, action, element, or component. It will be further understood that, although explicitly indicated, it does not exclude the presence or addition of one or more other features, integers, steps, actions, elements, components, or groups thereof. In addition, the term “or” has the same meaning as the Boolean operator “OR”, ie, includes the possibility of “any” and “both”, and unless otherwise specified, “exclusive logic” It should be understood that it is not limited to “sum” (“XOR”). It is also to be understood that the symbol “/” between two adjacent words has the same meaning as “or” unless stated otherwise. Furthermore, phrases such as “connected to”, “coupled to”, or “communicating with” are not limited to direct connections, unless explicitly stated otherwise.

  Any reference to elements using the designations “first,” “second,” etc. herein generally does not limit the quantity or order of those elements. Rather, these designations may be used herein as a convenient way of distinguishing between two or more elements or examples of elements. Thus, a reference to a first element and a second element does not mean that only two elements can be used there, or that the first element must somehow precede the second element . Also, unless otherwise stated, a set of elements may comprise one or more elements. In addition, terms used in the description or claims in the form of “at least one of a, b, or c” or “a, b, c, or any combination thereof” are “a or b Or c or any combination of these elements. For example, the term may include a, or b, or c, or a and b, or a and c, or a and b and c, or 2a, or 2b, or 2c, or 2a and b.

  As used herein, the term “determining” encompasses a wide variety of activities. For example, “determining” is calculating, calculating, processing, deriving, examining, looking up (eg, looking up in a table, database or another data structure) Confirmation, etc. Also, “determining” can include receiving (eg, receiving information), accessing (eg, accessing data in a memory) and the like. Also, “determining” can include resolving, selecting, choosing, establishing and the like.

  While the above disclosure represents exemplary embodiments, it should be noted that various changes and modifications can be made herein without departing from the scope of the appended claims. The functions, steps or activities of a method claim according to aspects described herein need not be performed in any particular order unless explicitly stated otherwise. Further, although elements may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.

100 satellite communication systems
106 Infrastructure
108 Internet
110 PSTN
112 Forward feeder link
114 Return feeder link
116 Return service link
118 Forward Service Link
122 Handoff controller
124 Handoff controller
126 Signaling
130 Handoff information generator
132 Handoff information transmission controller
134 Handoff information
136 Handoff Information Request Controller
138 Handoff information
200 GN
201 GN, ground network
205 Antenna
210 RF subsystem
212 RF transceiver
214 RF controller
216 Antenna controller
220 Digital subsystem
222 Digital receiver
224 digital transmitter
226 BB processor
228 CTRL processor
230 PSTN interface
232 processing circuit
234 Memory device
236 Handoff controller
240 LAN interface
245 GN interface
250 GN controller
251 Local time / frequency / location criteria
300 satellites
301F Forward feeder link
301R Return feeder link
302F Forward feeder link
302R Return feeder link
310 forward transponder
311 First bandpass filter
312 First low-noise amplifier
313 Frequency converter
314 Second low noise amplifier
315 Second bandpass filter
316 power amplifier
320 Return transponder
321 First bandpass filter
322 First low noise amplifier
323 frequency converter
324 Second low noise amplifier
325 Second bandpass filter
326 power amplifier
330 oscillator
340 controller
351 Forward link antenna
352 Forward link antenna
361 Return link antenna
362 return link antenna
400 user terminals
401 User terminal
410 Antenna
412 Duplexer
414 analog receiver
416 digital data receiver
418 Searcher Receiver
420 control processor
422 Digital baseband circuit
426 transmit modulator
428 Digital Transmit Power Controller
430 analog transmit power
432 memory
434 Local time / frequency / location criteria
442 Processing circuit
444 Memory device
446 Handoff controller
450 UE interface circuit
500 user equipment
501 User equipment
502 LAN interface
504 antenna
506 WAN transceiver
508 WLAN transceiver
510 SPS receiver
512 processor
514 Motion sensor
516 memory
518 data
520 instructions
522 User interface
524 Microphone / speaker
526 keypad
528 display
600 Communication system
602 First device
604 second device
606 Idle mode handoff information
608 transmitter
610 Idle Mode Handoff Information
612 receiver
614 Idle Mode Handoff Information
700 Non-geostationary satellite communication system
702 UT
704 Terrestrial network
712 NAC
714 RF subsystem
716 CNCP
718 CNUP
720 other networks
722 Handoff information
724 Idle Mode Handoff Information
726 Idle mode handoff information
728 Handoff information
800 signaling call flow
802 UT
804 GN
808 Idle mode handoff table request message
810 UL location report message
812 Idle mode handoff table response message
900 timeline
908 Paging Opportunity
1000 Satellite communication system
1002 UT
1004 GN
1008 Transition information
1010 UT information
1012 First signaling
1014 Second signaling
1016 Measurement message
1018 NAC
1020 RF subsystem
1022 CNCP
1024 CNUP
1026 Other networks
1028 Network entity
1030 controller
1102 UT
1104 GN
1106 Source NAC
1108 Control signaling
1110 packet data
1112 Handoff trigger
1114 Handoff processing
1116 Target NAC
1120 Handoff signaling
1124 Synchronous signaling for new satellites
1126 Connection signaling
1128 connection signaling
1202 UT
1204 GN
1206 Source NAC
1208 Control signaling
1210 packet data
1212 Handoff trigger
1218 Measurement message
1220 Target NAC
1222 Handoff processing
1226 Handoff signaling
1230 Synchronous signaling for new satellites
1232 connection signaling
1234 connection signaling
1306 UT
1308 AxP (ACP / ATP)
1310 Satellite RF Subsystem
1312 BxP (BCP / BTP)
1400 graph
1402 Expected first beam
1404 Expected second beam
1406 shifted first beam
1408 Shift of gain contour
1410 1st intersection
1412 Second intersection
1414 Expected handoff time
1416 Gain in expected handoff time
1418 New handoff time
1420 Gain at new handoff time
1502 UT
1504 Source BxP
1506 Target BxP
1508 source AxP
1510 GN
1512 packet data
1514 packet data
1516 packet data
1518 points
1520 packet data
1522 packet data
1524 packet data
1602 UT
1604 source BxP
1606 Target BxP
1608 source AxP
1610 GN
1612 packet data
1614 packet data
1616 packet data
1618 packet data
1620 packet data
1622 packet data
1624 packet data
1626 packet data
1628 packet data
1702 UT
1704 Source BxP
1706 Target BxP
1708 source AxP
1710 GN
1712 packet data
1714 packet data
1716 packet data
1718 parentheses
1720 points
1722 blocks
1724 packet data
1726 packet data
1728 packet data
1802 UT
1804 Source BxP
1806 Target BxP
1808 source AxP
1810 GN
1812 packet data
1814 packet data
1816 packet data
1818 packet data
1820 packet data
1822 packet data
1824 packet data
1826 packet data
1828 packet data
2002 UT
2004 Source BxP
2006 Target BxP
2008 Source AxP
2010 GN
2012 Target AxP
2014 MM
2016 packet data
2018 packet data
2020 packet data
2022 Packet data transfer
2024 packet data transfer
2028 packet data transfer
2030 blocks
2032 packet data
2034 packet data
2036 packet data
2038 packet data
2040 packet data
2042 End marker packet
2044 arrow
2046 arrow
2048 End marker packet
2050 packet data
2052 packet data
2054 packet data
2056 packet data
2302 UT
2304 Source BxP or Target BxP
2306 Source AxP or Target BxP
2312 packet data
2314 packet data
2400 processes
2500 process
2600 process
2700 processes
2800 process
2900 process
3000 processes
3100 process
3200 process
3300 process
3400 process
3900 equipment
3902 communication interface
3904 Storage media
3906 User interface
3908 memory device
3910 Processing circuit
3912 Antenna
3914 transmitter
3916 receiver
3918 Idle Mode Handoff Information
3920 Circuit / module for identification
3922 Circuit / module for deciding whether to transmit
3924 Circuits / modules to transmit
3926 Circuits / modules for receiving
3928 Circuits / modules for handoff
3930 Circuit / module for determining position information
3932 Code to identify
3934 Code for deciding whether to send
3936 Code to send
3938 Code to receive
3940 Code for handoff
3942 Code for determining location information
4000 processes
4100 process
4200 process
4300 equipment
4302 Communication interface
4304 Storage media
4306 User interface
4308 Memory device
4310 Processing circuit
4312 Antenna
4314 transmitter
4316 receiver
4318 Idle mode handoff information
4320 Circuit / module for identification
4322 Circuit / module for deciding whether to transmit
4324 Circuits / modules for transmitting
4326 Circuits / modules for receiving
4328 Circuits / modules to generate
4330 Circuits / modules for determining movement
4332 Circuit / module to determine how many entries to send
4340 Code to identify
4342 Code for deciding whether to send
4344 Code to send
4346 Code to receive
4348 Code to generate
4350 Code for determining movement
4352 Code to determine how many entries to send
4400 process
4500 process
4600 equipment
4602 communication interface
4604 Storage media
4606 User interface
4608 memory device
4610 processing circuit
4612 Antenna
4614 transmitter
4616 receiver
4618 Satellite related information
4620 circuit / module for generating
4622 Circuits / modules for transmitting
4624 Circuits / modules for performing handoffs
4626 Circuits / modules to receive
4628 Circuit / module for deciding whether to fix
4630 Circuit / module for choosing
4632 Circuits / modules for determining time
4634 Circuits / modules to transfer
4636 Circuits / modules for determining measurement gaps
4638 Circuit / module for determining that no measurement gap is required
4640 code to generate
4642 Code to send
4644 Handoff code
4646 Code for receiving
4648 Code for deciding whether to fix
4650 code for choosing
4652 Code for determining time
4654 Code to transfer
4656 Code for determining the measurement gap
4658 Code for determining that a measurement gap is not required
4700 processes
4800 process
4900 equipment
4902 communication interface
4904 Storage media
4906 User interface
4908 memory device
4910 Processing circuit
4912 Antenna
4914 transmitter
4916 receiver
4918 satellite related information
4920 Circuit / module for receiving
4922 Circuit / module for performing handoff
4924 Circuits / modules for measuring signals
4926 Circuits / modules for transmitting
4928 Circuit / module for deciding whether to transmit
4930 Circuit / module for performing random access procedure
4932 Code to receive
4934 Code to perform handoff
4936 Code for measuring signals
4938 Code to send
4940 Code for deciding whether to send
4942 Code to perform random access procedure
5000 processes
5100 process

Claims (26)

A method of communication for a device, comprising:
Identifying a time associated with a particular entry of the set of handoff entries, said set of handoff entries including an idle mode handoff table, wherein the idle mode handoff table includes a start time for handoff to a particular satellite. The set of handoff entries identifies a set of satellites for handoff of the device;
Determining whether to send a request to send an updated set of handoff entries based on a comparison of the specified time and a current time ;
Sending the request for sending an updated set of handoff entries if the decision is to send the request.   The method of claim 1, wherein the time includes a start time of a handoff to one satellite of the set of satellites.   The method of claim 1, wherein the particular entry comprises the last entry in the set of handoff entries.   The method of claim 1, wherein the set of satellites is for idle mode operation of the device.   The method of claim 1, wherein the time indicates when the device should handoff to one satellite of the set of satellites while the device is in idle mode.   The method of claim 1, further comprising transmitting the time indication with the transmission of the request.   The method of claim 1, further comprising sending an indication of a validity time associated with the set of handoff entries along with the sending of the request. Receiving the updated set of handoff entries after sending the request;
2. The method of claim 1, further comprising handing off the device to a satellite identified by the updated set of handoff entries at a time indicated by the updated set of handoff entries. Further comprising receiving an indication of at least one carrier frequency that a next cell providing coverage for the device will use to transmit;
9. The method of claim 8, wherein the handoff to the satellite identified by the updated set of handoff entries occurs at the at least one carrier frequency. Determining position information of the device;
The method of claim 1, further comprising: transmitting the location information with the transmission of the request. A device for communication,
Memory,
A processor coupled to the memory;
The processor and the memory,
Identifying a time associated with a particular entry of a set of handoff entries, wherein the set of handoff entries includes an idle mode handoff table, wherein the idle mode handoff table indicates a start time of a handoff to a particular satellite. and it contains an entry, the set of handoff entry identifies a set of satellites for handoff of the device, identifies shown,
Determining whether to send a request to send an updated set of handoff entries based on a comparison of the identified time and a current time ;
An apparatus configured to send the request for sending an updated set of handoff entries if the determination is to send the request; A method of communication for a device, comprising:
Identifying the amount of valid entries in the set of handoff entries, wherein the set of handoff entries includes an idle mode handoff table, the set of handoff entries comprising a set of satellites for handoff of the device. Identify, step,
Determining whether to send a request to send an updated set of handoff entries based on the identified amount;
Sending the request for sending an updated set of handoff entries if the decision is to send the request.   13. The method of claim 12, wherein the set of handoff entries further identifies a time at which the device in idle mode should handoff to each satellite of the set of satellites. The determination of whether to send the request for an updated set of handoff entries;
13. The method of claim 12, comprising determining whether the set of handoff entries includes only one valid entry. Receiving the updated set of handoff entries after sending the request;
13. The method of claim 12, further comprising handing off the device to a satellite identified by the updated set of handoff entries at a time indicated by the updated set of handoff entries. Further comprising receiving an indication of at least one carrier frequency that a next cell providing coverage for the device will use to transmit;
16. The method of claim 15, wherein the handoff to the satellite identified by the updated set of handoff entries occurs at the at least one carrier frequency. Determining position information of the device;
13. The method of claim 12, further comprising: transmitting the location information with the transmission of the request. A method of communication for a device, comprising:
Identifying a valid time associated with a set of handoff entries, the set of handoff entries including an idle mode handoff table, wherein the valid time indicates a length of time that the set of handoff entries is valid. The set of handoff entries identifies a set of satellites for handoff of another device; and
Determining whether to send an updated set of handoff entries based on the identified validity time;
Sending the updated set of handoff entries if the determination is to send the updated set of handoff entries. The identification of the valid time is
19. The method of claim 18, comprising receiving the valid time indication. The identification of the valid time is
Receiving an indication of a time associated with a particular entry in the set of handoff entries;
19. The method of claim 18, comprising determining the valid time based on the received indication. The identification of the valid time is
19. The method of claim 18, comprising determining a time associated with the last valid entry in the set of handoff entries.   The method of claim 18, wherein the set of handoff entries comprises a final set of handoff entries sent by the device to another device. Receiving position information of another device;
Generating the updated set of handoff entries based on the location information; and
19. The method of claim 18, wherein the updated set of handoff entries is sent to another device. Further comprising receiving location information of another device;
19. The method of claim 18, wherein the determination of whether to send the updated set of handoff entries is further based on the location information. Receiving position information of another device;
Further determining the movement of the other device based on the position information,
19. The method of claim 18, wherein the determination of whether to send the updated set of handoff entries is further based on the movement of the other device. Receiving position information of another device;
Determining the movement of the other device based on the position information;
19. The method of claim 18, further comprising: determining how many updated handoff entries to send based on the movement of the other device.