Cellular API for satellite configuration

Abstract

The UE (110) receives satellite ephemeris information (122) from the server (116) and calculates one or more satellite parameters for the at least one satellite (112) based on the satellite ephemeris information. The UE controls operation of a software application (117, 118) that utilizes a data service provided via the at least one satellite based on the one or more satellite parameters. Calculating the satellite parameters may include calculating the one or more satellite parameters at an API (120) of the UE, and controlling operation of the software application may include receiving, at the API, a request for the satellite ephemeris information from the software application, the API providing a representation of the one or more satellite parameters to the software application in response to the request, and adjusting, at the software application, operation of the software application based on the received representation of the one or more satellite parameters.

Description

[Background technology]

[0001] background Wireless communication systems often employ a variety of technologies to facilitate communication between mobile user equipment (UE) and associated base stations. These technologies often benefit from the fact that base stations are typically stationary. However, with the development of satellite-based communications with UEs, the mobility of satellites further complicates efforts to provide adequate coverage, latency, throughput, and reliability in communications between the UE and one or more satellites that provide communications services to the UE.

[0002] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings, in which: The use of the same reference symbols in different drawings indicates similar or identical items. [Brief explanation of the drawings]

[0003] [Figure 1] 1 is a block diagram illustrating a satellite-based wireless communication system employing an application programming interface (API) for providing satellite ephemera, according to some embodiments. [Figure 2] 2 is a block diagram illustrating a server of the wireless communication system of FIG. 1 according to some embodiments. [Figure 3] 2 is a block diagram illustrating a UE of the wireless communication system of FIG. 1, according to some embodiments. [Figure 4] FIG. 1 is a flow diagram illustrating a method for providing satellite ephemera via an API, according to some embodiments. [Figure 5] 1A-1C illustrate various example operations of a UE utilizing a satellite API, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] Detailed Description The development of satellite communications suitable for use by cellular-enabled user equipment (UE) allows such UEs to utilize satellite-supported data services in addition to traditional terrestrial cellular data services, including those supported by cellular networks employing communications technologies based on the Third Generation Partnership Project (3GPP®) fourth-generation (4G) Long Term Evolution (LTE) and fifth-generation (5G) New Radio (NR) standards. However, unlike most base stations employed in terrestrial wireless networks, satellites provided by various satellite operators are constantly moving, and a UE cannot easily determine the current location of a given satellite without prior knowledge of the satellite's specific ephemeris (e.g., altitude and velocity). This position uncertainty, as well as uncertainty in certain other satellite status information such as deployed active beams and transmit power, can make it difficult for the UE to establish an initial connection with the satellite. Furthermore, without a mechanism for the satellite to keep the UE updated on its various operating parameters, it can be difficult for the UE to manage an established connection with the satellite.

[0005] 1-5 illustrate exemplary systems and techniques for facilitating adapting the operation of a UE's software applications to the characteristics of one or more satellites providing data services to the UE. In at least one embodiment, one or more satellite operators provide current satellite ephemeris information to a server (e.g., as part of a cloud-based service). The server receives and processes this information and stores the resulting processed satellite ephemeris information in a database or other data store. When updated satellite ephemeris information is provided by the satellite operator, the server updates the data store accordingly. The satellite ephemeris information provided by the satellite operator may include location information such as current velocity (speed and direction) and current altitude. It may also include identification of one or more beams currently active on the satellite, and operational status information such as the beam numerical aperture, angle or direction, and transmit power for each active beam. The UE implements an application programming interface (API) or other software interface in its operating system (OS) to retrieve relevant satellite ephemeris information from the server and process the retrieved satellite ephemeris information to control the operation of one or more software applications in the UE that rely on satellite-provided data services.

[0006] To this end, in some embodiments, the API is configured to generate a request for satellite ephemeris information in response to a trigger, which may be a periodic or scheduled trigger, a trigger initiated by a software application requesting the information, or the like. The UE sends the request to the server via a wireless cellular connection with a base station connected to the server. In response to receiving the request, the server accesses the requested satellite ephemeris information and provides the information for transmission back to the UE. The API receives the provided satellite ephemeris information and calculates one or more satellite parameters for one or more satellites from this information. These satellite parameters may include latency or throughput estimates, beam coverage maps, etc. The API then provides one or both of the calculated satellite parameters and / or the satellite ephemeris information to one or more software applications, which use the provided information to adjust or otherwise control their operations. For example, based on the calculated throughput and latency operations, the software applications may throttle the data rates employed for the data streams supported by the corresponding satellites. As another example, depending on the estimated length of time that the UE will remain within the coverage area of ​​a satellite, the software application may pre-buffer certain data in anticipation of a loss of satellite coverage.

[0007] In this manner, by centralizing and consolidating satellite ephemeris information for multiple satellites from multiple carriers in a server, facilitating access to such information via an API or other OS-based interface, and pre-calculating certain satellite parameters from the satellite ephemeris information accessed in the API or other interface, individual software applications in the UE can more seamlessly adapt their operation to current satellite communications conditions.

[0008] 1 illustrates a communications system 100 employing cloud-based satellite ephemera provisioning, according to some embodiments. In the illustrated example, the communications system 100 includes a terrestrial wireless network 102, one or more satellite networks 104 (such as the illustrated satellite networks 104-1 and 104-2), and a cloud service 106. The terrestrial wireless network 102 includes a cellular configuration, with each cell of the network 102 served by a corresponding base station 108 connected to a core network (not shown), which in turn connects to the cloud service 106 via one or more networks, such as the Internet. Alternatively, the cloud service 106 may be implemented in the core network or may otherwise be a component of the terrestrial wireless network. The base stations 108 support one or more cellular radio access technologies (RATs), e.g., 4G LTE RAT or 5G NR RAT, where the base stations 108 are often identified as enhanced NodeBs (eNBs) or Next Generation NodeBs (gNBs), respectively. Base station 108 is configured to conduct wireless communication with one or more UEs within its coverage area, including UE 110, using a corresponding RAT.

[0009] Each satellite network 104 is managed by a corresponding satellite operator and includes one or more telecommunications satellites in orbit around the Earth and in wireless communication with one or more gateway ground stations, or simply "gateways" (also commonly referred to as ground stations, teleports, or hubs). Illustratively, satellite network 104-1 includes telecommunications satellite 112 in wireless communication with gateway 114. Each gateway, in turn, is connected to one or more networks via various wired or wireless connections.

[0010] The cloud service 106 includes at least one server 116 and associated support equipment. The server 116 is connected via one or more wired or wireless networks to one or more gateways or other interface components of each satellite network 104, and is further connected via one or more wired or wireless networks to a base station 108 (or core network) of the terrestrial wireless network 102 (or, as described above, the server 116 may be part of the core network of the terrestrial wireless network 102). As described in more detail herein, the cloud service 106, via the server 116, operates to receive and process satellite ephemeris information from one or more satellite networks 104 and store the resulting current satellite ephemeris information for subsequent distribution to requesting UEs of the terrestrial wireless network 102.

[0011] The UE 110 may comprise any of a variety of electronic devices configured to engage in wireless signaling with various terrestrial radio access networks (RANs) via corresponding base stations, including the illustrated terrestrial wireless network 102 and its base stations 108, as well as one or more satellite RANs via one or more corresponding telecommunications satellites, such as telecommunications satellite 112 of satellite network 104-1. Thus, examples of the UE 110 may include smartphones, smart watches or other wearable devices, notebook and tablet computers, wireless-enabled vehicles, and the like. To establish and maintain a wireless connection with the base station 108, the UE 110 may utilize any of a variety of well-known techniques appropriate for the corresponding terrestrial RAT employed. These techniques are facilitated by the typically stationary configuration of the base station 108 and the ability of the UE 110 and base station 108 to assess and adapt to the capabilities of the other, due in part to the relative proximity of the two components. However, in the case of establishing a satellite connection, the uncertainty in the relative distance between the UE and the corresponding satellite, the relative motion of the satellite with respect to the UE, the specific position and other parameters of the satellite, and the lack of a mechanism to directly communicate this information to the UE often disproportionately complicate the UE's ability to establish a satellite connection and operate in accordance with the satellite's current operating environment.

[0012] Thus, to facilitate the UE understanding the current status of the satellites so that software applications that rely on the data services provided by the satellites can adapt their operation accordingly, in at least one embodiment, cloud service 106 operates to provide integrated and unified satellite ephemeris information to these software applications of UE 110, such as software applications 117, 118, via satellite API 120 implemented by the operating system (OS) or other software layer of UE 110. As a general operational overview, gateway 114 or other component of each satellite network 104 provides satellite ephemeris information 122, such as satellite ephemeris information 122-1 and satellite ephemeris information 122-2, to cloud service 106 periodically or in response to some other trigger. The server 116 of the cloud service 106 receives this information, filters it, formats it to conform to a standardized format, and updates a database or other data store (e.g., the ephemeris database 212 of FIG. 2 ) with the resulting processed information, such that the database stores the most recent satellite ephemeris information for the satellites 112 of the supported satellite network 104. The provided satellite ephemeris information 122 may include certain parameters related to the physical status of the satellites 112, such as a current altitude 125 and a current speed 127. The satellite ephemeris information 122 may further include an identifier for one or more beams 130 currently active at the satellite 112, and, for each identified active beam 130, information regarding its current radio frequency (RF) operational parameters, such as one or more of the beam type (e.g., wide beam or spot beam), the aperture 132 of the active beam 130, and the direction 134 (or angle) of the active beam 130.Additionally, the satellite ephemeris information 122 may include an indicator of the satellite's current transmit power, such as in the form of an Effective Radiated Power (ERP) or Effective Isotropic Radiated Power (EIRP) parameter, for all active beams 130 or for each beam.

[0013] In response to a specified trigger, such as the expiration of a periodic timer or a request for information from one of the software applications 117, 118, the satellite API 120 sends a request 126 for satellite ephemeris information to the server 116 via a wireless data connection between the UE 110 and the base station 108, and then as a wired or wireless connection between the BS 108 and the cloud service 106. By way of example, the request 126 may be formatted as a Hypertext Transfer Protocol (HTTP) GET request, a Representative State Transfer (REST) ​​request, other client-server protocols, or the like. In at least one embodiment, the request 126 includes an identifier for a particular satellite or a particular satellite operator for which satellite ephemeris information is to be provided. For example, the UE 110 may utilize a subscriber identity module (SIM) card associated with a corresponding satellite operator and may provide the satellite operator identifier in the SIM card as part of the request 126. The request 126 may further include applicable UE capabilities, such as frequency bands supported by the UE 110, in some embodiments. The server 116 receives the request 126, accesses the current satellite ephemeris information requested by the request 126 from a database, and sends a response 128 containing the requested satellite ephemeris information to the UE 110 via the base station 108, such as in the form of an HTTP response or a REST response. The API 120 receives the response 128 and extracts the satellite ephemeris information.

[0014] In at least one embodiment, to promote broad interoperability and reduce duplication of effort on the part of multiple software applications, satellite API 120 is configured to interpret satellite ephemeris information on behalf of the software applications to calculate one or more satellite parameters from the satellite ephemeris information and then provide these one or more satellite parameters to software applications 117, 118 in addition to, or instead of, the software ephemeris information obtained from answer 128. For example, rather than having each software application perform its own individual calculations to estimate the throughput and latency of the wireless connection between UE 110 and satellite 112 based on the satellite ephemeris information, satellite API 120 can perform these calculations once and then provide the same resulting throughput and latency estimates to each software application 117, 118. Furthermore, satellite API 120 may be able to determine further certain current satellite parameters using current UE parameter information that the software applications may not have access to. As an example, in some embodiments, the satellite API 120 utilizes one or more of the parameters representing the altitude 125 and velocity 127 of the satellite 112 and the beam angle 134 and beam aperture 132 of the active beam 130 of the satellite 112, as provided in the satellite ephemeris information of the response 128, to calculate a current beam coverage map representing the effective geographic service area of ​​the active beam 130. The satellite API 120 may then utilize the current position of the UE 110, as provided, for example, via a Global Positioning System (GPS) sensor, to determine the current position of the UE 110 within the current beam coverage map and further estimate the length of time the UE 110 will remain within the current beam coverage map based on the position of the UE 110, the velocity of the UE 110, and the velocity 127 of the satellite 112. An indicator of the estimated time remaining within the current coverage may then be provided to one or both of the software applications 117, 118.

[0015] Software application 117, 118 uses one or more current satellite parameters calculated by satellite API 120, and possibly the provided satellite ephemeris information itself, to adapt its operation to the current satellite link environment represented by these provided parameters. Illustratively, one or both of the latency estimate and the throughput estimate may be used by software application 117 to throttle the data rate of a data stream uploaded or downloaded by software application 117 over the satellite data connection, or by software application 118 to adjust certain operating parameters, such as encoder / decoder (codec) parameters employed by software application 118's encoder used to encode an upstream multimedia stream or by an encoder of a server providing a downstream multimedia stream to UE 110.

[0016] 2 illustrates an example configuration of a server 116 of the cloud service 106 of FIG. 1 , according to some embodiments. As illustrated, the server 116 includes one or more network interfaces 202, one or more processors 204, and one or more non-transitory computer-readable media 206. Each of the one or more network interfaces 202 is coupled to a corresponding network and may include a wired interface (such as a wired Gigabit Ethernet interface), a wireless interface (such as an IEEE 802.11-based wireless interface), etc. The one or more processors 204 may include, for example, one or more central processing units (CPUs), graphics processing units (GPUs), artificial intelligence (AI) accelerators, or other application-specific integrated circuits (ASICs), etc. The computer-readable medium 206 may include any of a variety of media used by electronic devices to store data and / or executable instructions, such as random access memory (RAM), read-only memory (ROM), cache, flash memory, solid-state drive (SSD), or other mass storage device. For ease of explanation and brevity, the computer-readable medium 206 will be referred to herein as "memory 206" in light of the frequent use of system memory or other memory for storing data and instructions for execution by the processor 204, although it will be understood that reference to "memory 206" applies equally to other types of storage media unless otherwise specified.

[0017] The one or more memories 206 of the server 116 are used to store one or more sets of executable software instructions and associated data that operate the one or more processors 204 and other components of the server 116 to perform the various functions described herein and attributed to the server 116. Examples of sets of executable software instructions include an operating system (OS) and various drivers (not shown), various software applications (not shown), an ephemera aggregator 208, and an API manager 210. Data stored in the one or more memories 206 includes an ephemera database 212, which is identified herein as a “database” for ease of reference but may include any one or combination of various data structures or other data stores. The ephemera database 212 stores satellite ephemeris information for one or more satellites of one or more satellite networks, such as satellite 112 of satellite network 104-1 (FIG. 1). The ephemera aggregator 208 operates to receive, for each satellite supported by the server 116, current satellite ephemeris information from a gateway or other component of the satellite network that operates the satellite. This information may be provided periodically or according to a specified schedule, as part of an information push from a satellite operator, in response to a query from the ephemera aggregator 208 to the corresponding satellite operator. The ephemera aggregator 208 then updates the satellite ephemeris information for the corresponding satellite in the ephemera database 212 to reflect the current status of the corresponding satellite.

[0018] The format of the satellite ephemeris information provided by the satellite carrier may not match the format of the satellite ephemeris information expected by the satellite API 120 of the UE 110 that the server supports. Furthermore, in some embodiments, the server 116 supports multiple satellite networks and multiple satellite carriers, each of which may format the provided satellite ephemeris information differently. Thus, in at least one embodiment, the ephemeris aggregator 208 processes the received satellite ephemeris information to be compatible with the expected format provided to the satellite API 120. This may include filtering the received information by removing parameters not tracked by the server 116, removing duplicate or redundant information, etc. This processing may also include reformatting the information, such as unit conversions (e.g., converting miles per hour to meters per second), reorganizing data values, harmonizing numbering formats, etc.

[0019] API manager 210 operates to process requests for satellite ephemeris information (e.g., requests 126) received from satellite API 120 of UEs 110 in system 100, query or otherwise access ephemeris database 212 based on the received requests, and provide the requested and accessed satellite ephemeris information as corresponding answers (e.g., answers 28) to satellite API 120 via base station 108 and the wireless link connecting base station 108 and UE 110. By way of example, in an implementation in which satellite API 120 submits its requests 126 as HTTP requests, API manager 210 may be implemented as an HTTP server that processes such HTTP requests.

[0020] 3 illustrates an example configuration of a UE 110 of the system 100 of FIG. 1 , according to some embodiments. In the illustrated configuration, the UE 110 includes, for each RAT, one or more antenna arrays 302, each having one or more antennas 303, a radio frequency (RF) interface 304, and a corresponding modem 306. For example, for terrestrial wireless communications, the UE 110 may include a set of one or more antenna arrays 302, one or more RF interfaces 304, and one or more modems 306 to support 4G LTE or 5G NR signaling with a base station 108, these components being collectively referred to as a “cellular interface.” For satellite communications, the UE 110 may include another set of one or more antenna arrays, one or more RF interfaces 304, and one or more modems to support wireless signaling with a satellite 112 of a corresponding satellite network 104, these components being collectively referred to as a “satellite interface.”

[0021] The UE 110 further includes one or more processors 308 and one or more non-transitory computer-readable media 310. The one or more processors 308 may include, for example, one or more CPUs, GPUs, AI accelerators, or other ASICs. The computer-readable media 310 may include any of a variety of media used by electronic devices to store data and / or executable instructions, such as RAM, ROM, cache, flash memory, SSD, or other mass storage device. For ease of explanation and brevity, the computer-readable media 310 will be referred to herein as “memory 310,” although it will be understood that reference to “memory 310” applies equally to other types of storage media unless otherwise specified.

[0022] The one or more memories 310 of the UE 110 are used to store one or more software applications (e.g., software applications 117, 118 of FIG. 1 ) in the form of sets of executable software instructions and associated data that operate the one or more processors 308, modem 306, RF interface 304, and other components of the UE 110 to perform various functions described herein and attributed to the UE 110. The software includes various software applications, including, for example, an OS 312 and associated drivers (not shown), as well as a telephony platform 314 that manages telephony and data connections provided by the terrestrial wireless network 102 and satellite network 104, a set of software applications and APIs that facilitate inter-device functionality, such as a Google® Mobility Services (GMS) core 316, and one or more user software applications, such as user software applications 318 and 320. The user software applications 318 and 320 utilize data services provided by the terrestrial wireless network 102 and satellite network 104. Examples of such applications include navigation and mapping applications, video streaming applications, packetized data telephony applications, video conferencing applications, gaming applications, web browsing applications, etc. The set of stored executable instructions further includes a satellite API 120. In the illustrated embodiment, the satellite API 120 is implemented as part of the OS 312 or its associated services. However, the satellite API 120 may be implemented in any of various software components of the UE 110, such as as part of the GMS core 316 or the telephony platform 314.

[0023] During operation, some software applications of the UE 110 may utilize various information regarding the state or status of the UE 110, referred to herein as “UE local information,” which is stored in one or more data stores or other data structures in one or more memories 310. These data structures and the information contained therein are collectively referred to herein as “UE local information 322.” Examples of UE local information 322 include location information of the UE 110 obtained, for example, from a GPS sensor or visual odometry system, information regarding the RF capabilities of the UE 110, such as antenna gain or noise figure, information regarding remaining battery power, current power mode, etc.

[0024] 4 illustrates an exemplary method 400 for utilizing a satellite API 120 to provide control or adaptation of various software services in a UE 110 based on acquired satellite ephemeris information, according to some embodiments. Note that, for purposes of the illustrated example, a line 401 serves to indicate whether the server 116 or the UE 110 performs the described processing, with processing described with reference to blocks located to the left of the line 401 being performed by the server 116 and processing described with reference to blocks located to the right of the line 401 being performed by the UE 110.

[0025] The method 400 includes an iterative subprocess 402 for maintaining up-to-date data in the ephemera database 212 of the server 116. In this subprocess block, the server 116 obtains original or updated satellite ephemeris information 122 from one or more satellite networks 104. As described above, the ephemera aggregator 208 of the server 116 can periodically or according to a schedule poll or query a satellite operator for this information, or the satellite operator can push this information to the server 116 on its own schedule, etc. For each block of satellite ephemeris information 122 received from a satellite operator, in block 406 the ephemera aggregator 208 processes the information for inclusion in the ephemera database 212, which may include various processing such as unit conversion, conversion to a unified numeric representation, filtering of duplicate or irrelevant data, etc. The ephemera aggregator 208 then updates the ephemera database 212 with the resulting data. Sub-process iteration 402 is repeated for each instance of satellite ephemeris information received from the satellite carrier for one or more satellites.

[0026] The main process of providing satellite ephemeris to the satellite API 120 of the UE 110 for use in controlling the operation of the UE 110 begins at block 408 with the UE 110 generating a request for a satellite ephemeris update (e.g., request 126, FIG. 1 ) and wirelessly transmitting the request to the base station 108 for forwarding to the server 116. The trigger for the generation of the request may include, for example, a periodic or scheduled trigger, a request from one or more software applications of the UE 110, etc. The request may specify the particular satellite ephemeris information sought based on any of a variety of considerations, such as by identifying the satellite network 104 or satellite operator intended to support the UE 110, by providing a SIM identifier or other identifier of the UE 110, by identifying a particular satellite or set of satellites, by providing a current location identifier of the UE 110, etc. As mentioned above, the request may take the form of any of a variety of request formats often employed by APIs that interact with remote network data sources, such as a REST request or an HTTP GET request. In some embodiments, it is the satellite API 120 that initiates the request, while in other embodiments it may be a system application or a user application on the UE 110 that triggers the request generation.

[0027] At block 410, the API manager 210 of the server 116 receives the request from the satellite API 120 of the UE 110 and accesses the ephemeris database 212 to obtain current satellite ephemeris information to fulfill the request. The particular information obtained may be based on the satellite operator or satellite network identified in the request 126, the location of the particular UE 110 or UE identified in the request, the particular set of one or more satellites identified in the request 126, etc. At block 412, the API manager 210 generates a reply (e.g., reply 128) including the accessed satellite ephemeris information and provides the reply to the network interface 202 for transmission to the base station 108, which wirelessly transmits the reply to the UE 110.

[0028] In block 414, the UE 110 receives the response from the server 116, and the satellite API 120 processes the response to extract the satellite ephemeris information contained therein and then updates its local data store of satellite ephemeris information to reflect the updated data contained in the response. Using the current and updated satellite ephemeris, the satellite API 120 calculates or determines one or more current satellite parameters for the specified satellite or set of satellites in block 416. The one or more specified satellites may be, for example, one or more satellites with which the UE 110 has a currently established wireless connection, one or more satellites with which the UE 110 is attempting to establish a wireless connection or is predicted to attempt to establish a wireless connection in the near future, etc. The one or more current satellite parameters may include any of a variety of data or information representing an indication of a parameter of the current status or resulting operation of the corresponding satellite. For example, the current satellite parameters for the specified satellite may include one or both of an estimate of the satellite's latency or throughput for the UE 110, an estimated current coverage area, etc. As described in the example of FIG. 5 below, the satellite API 120 may further calculate one or more current satellite parameters based on the UE local information 332, such as based on the current position of the UE 110 or the current antenna gain.

[0029] In block 418, the satellite API 120 provides one or both of some or all of the current calculated satellite parameters or some or all of the current satellite ephemeris information for one or more satellites of interest to one or more software applications of the UE 110. The specific information provided by the satellite API 120 may vary depending on the software application. For example, in some embodiments, the satellite API 120 may provide the satellite information only to the software application that requested that particular information (i.e., only to the software application that made the call to the satellite API 120). In other embodiments, an update to the satellite ephemeris information or one or more updates to the calculated satellite parameters may trigger the satellite API 120 to push some or all of the updated information to one or more software applications regardless of which software application initiated the request.

[0030] In block 420, the software application that receives the updated satellite parameters and / or updated satellite ephemeris information adjusts or otherwise controls one or more aspects of its operation based on the received information. Generally, controlling / modifying the software application's operation relates to the software application's use of wireless connections established or attempted to be established with the satellites represented in the updated information. This may include modifying software operation to adjust data usage, modifying operation in establishing, tearing down, or handing over satellite connections, etc.

[0031] 5 illustrates numerous non-limiting examples of controlling or modifying the operation of software applications of the UE 110 in response to satellite information provided by the software API 120, as represented by block 420 of the method 400 of FIG. 4. For the following examples, the server 116 provides updated satellite ephemeris information 502 that is used by the satellite API 120 to generate corresponding satellite parameters and satellite ephemeris used in these examples.

[0032] As shown by example 511, the satellite API 120 extracts a beam identifier for an identified beam (e.g., beam 130) in the satellite ephemeris information 520 and provides this beam identifier to a satellite interface (IF) 502 of the UE 110, which represents software in the modem 306 and telephony platform 314 used to control the antenna array 302 for satellite RF communications. The satellite IF 502 uses this beam identifier to quickly acquire the identified beam (i.e., quickly configure the antenna array 302 to establish a radio link with the satellite via the identified beam).

[0033] As shown by example 512, satellite ephemeris information 520 may include satellite ephemeris information for satellites from multiple satellite operators, such that satellite API 120 can extract active beam information for different satellites from different satellite operators and provide this information to satellite IF 502, which can use this information to support multiple simultaneous data connections with different operators in a manner similar to the Dual Sim / Dual Active (DSDA) or Dual Sim / Dual Standby (DSDS) process found in terrestrial cellular systems.

[0034] Example 513 illustrates the calculation of a serving satellite's current coverage area to control the operation of map software application 504. To illustrate, satellite ephemeris information 520 may include the current altitude 125 and velocity 127 of the current satellite 112 providing data service to UE 110, as well as an indicator of the beam aperture 132, beam angle 134, and EIRP of the active beam 130 acquired by UE 110. Satellite API 120 can use this information to calculate the current effective coverage area of ​​the acquired active beam 130 (i.e., the current effective "footprint" of the satellite's active beam 130). Satellite API 120 can then use UE 110's current position, current velocity, and current antenna gain to estimate the length of time UE 110 will remain within the satellite's 112 effective coverage area before handing over to a different satellite. The satellite API 120 provides an indication of the estimated time remaining to the map software application 504, which uses this information in determining whether to trigger pre-buffering of map information at the UE 110 prior to an expected handover so that the mapping / navigation services provided by the map software application 504 are not affected by the handover.

[0035] In example 514, the satellite API 120 uses the altitude, velocity, active beam identification, and transmit power indicators from the satellite ephemeris information 502, along with the location information and antenna gain and noise figure information from the UE local information 322, to calculate current throughput and latency estimates for the data connection between the UE 110 and the satellite and provide these estimates to the videoconferencing application 506 of the UE 110. The videoconferencing application 506 then uses either or both of the latency and throughput estimates to selectively throttle the data rate of either or both of the transmitted or received video streams for the videoconference taking place over the data link between the UE 110 and the corresponding satellite. For example, throughput can be estimated by dividing the amount of data delivered by the amount of time used to transmit and receive that amount of data. For latency, this metric can be estimated based on analysis of timestamps, packet queuing times, the distance between the UE 110 and the corresponding satellite, etc.

[0036] Example 515 similarly relies on the satellite API 120 calculating latency and throughput estimates that are provided to the video streaming application 508 of the UE 110. The video streaming application 508 can use these estimates to adapt one or both of the received video stream from the corresponding satellite or the transmitted video stream sent to the corresponding satellite by adjusting one or more codec parameters to better match the latency and throughput estimates. This may involve the video streaming application 508 adjusting its own encoding parameters of the transmitted video stream or requesting that a remote server adjust its encoding parameters of the received video stream.

[0037] In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, a solid-state storage device such as a magnetic or optical disk storage device, flash memory, a cache, random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other format of instructions that can be interpreted or otherwise executed by one or more processors.

[0038] A computer-readable storage medium may include any storage medium, or combination of storage media, that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tapes, or magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer-readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), permanently attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

[0039] It should be noted that not all of the activities or elements described above in the general description are required, that some of the particular activities or devices may not be required, and that one or more additional activities may be performed or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Furthermore, concepts have been described with reference to specific embodiments. However, those skilled in the art will recognize that various modifications and changes can be made without departing from the scope of the present disclosure, as defined in the following claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than restrictive sense, and all such modifications are intended to be within the scope of the present disclosure.

[0040] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, these benefits, advantages, solutions to problems, and any features that may cause or make any benefit, advantage, or solution more pronounced should not be construed as key, required, or essential features of any or all claims. Moreover, the specific embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as set forth in the claims below. It is therefore apparent that the specific embodiments disclosed above may be altered or modified, and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the following claims.

Claims

1. 1. A method in a user equipment, comprising: wirelessly receiving satellite ephemeris information for a set of one or more satellites from a server; calculating one or more satellite parameters for at least one satellite of the set based on the satellite ephemeris information; and controlling operation of a software application of the user equipment that utilizes a data service provided to the user equipment via the at least one satellite based on the one or more satellite parameters; The method, wherein controlling the operation of a software application includes pre-buffering data based on an amount of time the user equipment remains within coverage of the satellite.

2. Calculating one or more satellite parameters includes calculating one or more satellite parameters in an application programming interface (API) of the user equipment; Controlling the behavior of software applications receiving, at the API, a request for satellite ephemeris information from the software application; In response to receiving the request, the API provides a representation of the one or more satellite parameters to the software application; and and adjusting, in the software application, operation of the software application based on the representation of the one or more satellite parameters.

3. 3. The method of claim 1 or 2, wherein the satellite ephemeris information includes, for the set of satellites, at least one of: a velocity of the satellite; an altitude of the satellite; a transmit power indicator of the satellite; an indicator of one or more beams active at the satellite; an indicator of an aperture of an active beam of the satellite; and an indicator of an angle of an active beam of the satellite.

4. 4. The method of claim 1, wherein calculating one or more satellite parameters comprises calculating at least one of a throughput estimate or a latency estimate of a wireless connection available between the user equipment and a satellite based on the satellite ephemeris information.

5. Controlling the behavior of software applications throttling a data rate of the software application's data stream based on at least one of the throughput estimate or the latency estimate; and adjusting codec parameters of the software application based on at least one of the throughput estimate or the latency estimate.

6. 5. The method of claim 4, wherein calculating at least one of a throughput estimate or a latency estimate further comprises calculating the at least one of the throughput estimate or the latency estimate based on one or more current operating parameters of the user equipment.

7. The method of claim 6 , wherein the one or more current operating parameters of the user equipment include at least one of a current location, a current velocity, a satellite antenna gain, and a noise figure.

8. The method of any one of claims 1 to 7, wherein calculating one or more satellite parameters comprises calculating a current beam coverage map of a satellite based on the satellite ephemeris information.

9. 10. The method of claim 8, wherein calculating one or more satellite parameters further comprises calculating an estimate of an amount of time the user equipment will remain within the satellite's coverage area based on the current beam coverage map and the user equipment's current location.

10. 10. The method of claim 1, wherein controlling operation of a software application comprises configuring a satellite interface of the user equipment to support dual simultaneous connections with two satellites based on the one or more satellite parameters.

11. a cellular interface for wirelessly receiving satellite ephemeris information; a satellite interface for wireless communication with one or more satellites; a processor coupled to the cellular interface and the satellite interface; A user equipment comprising: a memory coupled to said processor and storing executable instructions configured to operate said processor to perform the method of any one of claims 1 to 10.

12. 1. A method in a server, comprising: receiving, from each of a plurality of satellite operators, first satellite ephemeris information for at least one satellite of a corresponding satellite operator; storing the first satellite ephemeris information in a data store of the server; and in response to receiving a request from a user equipment, accessing second satellite ephemeris information for at least one satellite from the data store, and wirelessly transmitting the accessed second satellite ephemeris information to the user equipment so as to perform the method of any one of claims 1 to 10.

13. receiving third satellite ephemeris information for at least one satellite of the corresponding satellite operator after receiving the first satellite ephemeris information from each of the plurality of satellite operators; 13. The method of claim 12, further comprising: storing the third satellite ephemeris information in the data store as updated satellite ephemeris information.

14. 14. The method of claim 12 or 13, wherein the first satellite ephemeris information includes at least one of a satellite velocity, a satellite altitude, a satellite transmit power indicator, an indicator of one or more beams active at the satellite, an indicator of an aperture of an active beam of the satellite, and an indicator of an angle of an active beam of the satellite.

15. A server configured to perform the method according to any one of claims 12 to 14.

16. 11. A computer program comprising instructions executable by a processor coupled to a cellular interface for wirelessly receiving satellite ephemeris information and to a satellite interface for wireless communication with one or more satellites, the instructions, when executed by the processor, causing the processor to perform a method according to any one of claims 1 to 10.

Images