Link service profile for predictive service control

Abstract

Systems and methods are provided for modifying application performance in view of link conditions. An example method includes predicting respective link rates of at least one link of a plurality of links delivering data to and from a vehicle while the vehicle is moving from an origin point to a destination point. The predictions are based on historical link characteristics. The method further includes generating a link service profile for the vehicle based on the predicted respective link rates and a route of the vehicle. Additionally, the method includes receiving a request from a mobile device for information related to the link service profile and transmitting an indication to the mobile device based on the link service profile, thereby causing a behavior of an application executing at the mobile device to be modified based on the link service profile.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit on the filing date of U.S. Provisional Patent Application No. 63 / 014,514, filed April 23, 2020, entitled “LINK SERVICE PROFILE FOR PREDICTIVE SERVICE CONTROL,” the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to a communication system for distributing data to and from mobile vehicles via a link, and more specifically, to generating link service profiles to modify the behavior of applications running on devices connected to the link. Background Technology

[0004] Many vehicles contain communication equipment that provides Internet services to devices carried by the vehicle. Because vehicles may move into and out of different types of coverage areas, the performance and reliability of wireless communication (i.e., Quality of Service (QoS)) may vary as the vehicle moves. When relying on Internet services carried by a vehicle, interruptions in the quality and reliability of the service can cause applications to operate inefficiently and ineffectively.

[0005] Specifically, applications running on a user's device are unaware of changes and interruptions to internet service. In fact, applications often assume a smooth, stable internet connection and operate no differently than they would in a traditional wireless network outside of transportation. For example, applications cannot know which application capabilities will actually be available during the journey. Due to this confusion, applications may present users with options that cannot be performed as expected if internet service were available on transportation. This confuses and disappoints users during their journey. As another example, applications may attempt to perform downloads during gaps in coverage, leading to reduced application efficiency and a degraded user experience.

[0006] Therefore, it is desirable to provide an effective method for optimizing the efficiency and usability of applications while the vehicle is in motion. Summary of the Invention

[0007] This summary introduces, in a simplified form, a series of concepts further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0008] In one embodiment, a method is provided for modifying application performance based on link conditions. The method includes a computing device of a system providing communication services to a mobile device carried by a vehicle predicting the corresponding link rate of at least one of a plurality of links. The plurality of links can deliver data to and from the vehicle while it is moving from a point of origin to a point of destination. The prediction may be based on historical link characteristics. The method may further include generating a link service profile for the vehicle based on the predicted corresponding link rate of the at least one link and the route of the vehicle between the point of origin and the point of destination. The method may further include receiving a request from the mobile device for information related to the link service profile, and transmitting an instruction based on the link service profile to the mobile device, thereby causing the behavior of an application executing on the mobile device to be modified based on the link service profile as the vehicle traverses the route.

[0009] In another embodiment, a computer-implemented method is provided, executed by a mobile device, to modify application performance in view of link conditions. The method includes sending a request to a computing device associated with a vehicle for information related to a link service profile. The link service profile may include predicted corresponding link rates for at least one of a plurality of links delivering data to and from the vehicle while it moves from a point of origin to a point of destination. The method may further include receiving an instruction based on the link service profile from the computing device, and modifying the behavior of an application executing on the mobile device while the mobile device is carried on the vehicle based on the instruction based on the link service profile.

[0010] In another embodiment, a non-transitory computer-readable storage medium may be provided for storing processor-executable instructions. When executed, the instructions cause one or more processors to send a request to a computing device associated with a vehicle for information related to a link service profile. The link service profile includes predicted link rates for at least one of a plurality of links that deliver data to and from the vehicle while it moves from a point of origin to a point of destination. The instructions may also cause a processor to receive instructions from the computing device based on the link service profile, and, based on the instructions, modify the behavior of an application executing on the mobile device while the mobile device is carried on the vehicle. Attached Figure Description

[0011] The accompanying drawings described below depict various aspects of the systems and methods disclosed herein. It should be understood that each drawing depicts an embodiment of a specific aspect of the disclosed systems and methods, and each drawing is intended to conform to one or more possible embodiments thereof. Further, whenever possible, the following description refers to the reference numerals included in the following drawings, wherein features depicted in the plurality of drawings are indicated by consistent reference numerals.

[0012] Figure 1A-1B Examples of instance communication systems capable of implementing the techniques disclosed herein for modifying application performance in light of link conditions are described.

[0013] Figure 2 This describes a vehicle that moves along a route and communicates via one or more links provided by one or more satellites.

[0014] Figure 3 It is a block diagram of an instance link service configuration file that can be generated and provided to a user device carried by a vehicle, such as... Figure 3 The vehicles depicted in the text;

[0015] Figures 4A-4B It is an exemplary interface displayed on a user device that is associated with application behavior modified according to a link service configuration file, such as... Figure 1A-1B One of the user devices;

[0016] Figure 5 This is an instance flowchart for instance methods used to modify application performance based on link conditions;

[0017] Figure 6 This is an instance flowchart of an instance method that can be executed by a user device to modify application performance based on link conditions; and

[0018] Figure 7 This is a block diagram of a user device that facilitates the techniques disclosed herein for modifying application performance. Detailed Implementation

[0019] While the following text provides a detailed description of many different embodiments, it should be understood that the legal scope of the invention is defined by the language of the appended claims. The detailed description is to be construed as merely exemplary and not as describing every possible embodiment, as describing every possible embodiment would be impractical, if not impossible. Several alternative embodiments may be implemented using the present technology or technology developed after the filing date of this patent, which still fall within the scope of the claims.

[0020] It should also be understood that unless a term is explicitly defined in this patent using the sentence “As used herein, the term '______' is hereby defined as meaning…” or a similar statement, there is no intention to explicitly or implicitly limit the meaning of the term beyond its explicit or ordinary meaning, and such terms should not be construed as limiting the scope based on any statement made in any part of this patent (other than the language of the claims). Any term referred to in this patent in a singular sense in the appended claims is for clarity, solely to avoid confusion for the reader, and is not intended to imply or otherwise limit the term of such claims to the singular sense. Finally, unless the scope of any claim element is defined by the function of the descriptive word “meaning” and the unstructured narration, it should not be intended to be interpreted based on the application of 35 U.SC § 112(f).

[0021] Traditionally, applications running on user devices aboard vehicles utilize onboard networks to provide various functionalities, such as streaming video, sending messages, and web browsing. Vehicles can provide onboard networks communicatively coupled to external communication links, which, in the case of aircraft, are, for example, satellite or air-to-ground (ATG) communication links. However, the quality of these external communication links, which deliver data to and from the vehicle, may vary as the vehicle moves. Typically, user devices are not aware in advance of changes in link conditions, nor do they have predictive information about the potential changes in link conditions. Applications assume a steady-state internet connection. Therefore, during a vehicle's journey, applications may attempt to perform functions that would be unsupported and / or malfunction due to coverage gaps and degradation, wasting computational resources. Consequently, users may be confused when the applicant presents them with indications that these capabilities are available. Users may attempt to click on or select capabilities that are, for example, unavailable under the current internet connection.

[0022] The techniques disclosed herein may include (1) generating predictive information about link rates during a vehicle's route, and (2) causing an application to modify its behavior by enabling the user device to access the predictive information. As previously mentioned, external communication links can deliver information to and from a vehicle while the vehicle is in motion. By analyzing the historical link characteristics of external communication links that provide communication services to the vehicle during its route, a computing device can predict what link rates and / or other link characteristics will exist on the planned route of the vehicle. Specifically, the computing device can predict the link characteristics of the route based on historical link characteristics and store them in a link service profile. In some embodiments, the computing device also updates the link service profile based on real-time changes in link conditions.

[0023] User devices carried on a vehicle can access a link service profile before and / or during the route. Applications on the user device can then modify their behavior based on the link characteristics contained in the link service profile. For example, if the link service profile indicates a low link rate unsuitable for video streaming at a specific time during the route, the application can anticipate the lower link rate and cache video data. The application can also notify the user of capability unavailability, for example, by "greying" the video streaming capability or otherwise informing the user that the capability is unavailable or will be unavailable. Therefore, this disclosure improves the functionality of applications running on devices mounted on a vehicle.

[0024] Figures 1A to 1B An environment 100 comprising an instance communication system is described, which is capable of implementing the techniques disclosed herein to modify application performance in light of external communication link conditions. For example... Figure 1A The environment 100 is depicted as potentially including a vehicle 105. While vehicle 105 is depicted as an airplane, it is envisioned that vehicle 105 could be any mode of transportation, such as a bus, train, subway, helicopter, ship, hot air balloon, etc. Furthermore, although... Figure 1A Only a single vehicle 105 is shown. In other embodiments, environment 100 may contain any number of vehicles configured similarly to vehicle 105.

[0025] Vehicle 105 may communicate with one or more links for delivering data in and out of vehicle 105. Specifically, the one or more links may include: an airborne communication link 137 for providing communication services to user equipment 110 while it is housed within vehicle 105; an air-to-ground (ATG) communication link 147 of an ATG network; and a satellite communication link 157 of a satellite communication system (including (a) a satellite communication link 157a between vehicle 105 and satellite 152, and (b) a satellite communication link 157b between vehicle 105 and satellite ground station 150, collectively referred to herein as satellite communication link 157). ATG communication link 147 may be between vehicle 105 and a terrestrial base station 145 connected to a public switched telephone network (PTSN) 148. Although ATG communication link 147 and satellite communication link 157 are referred to herein in the singular, it should be understood that other network configurations are also contemplated. For example, vehicle 105 may be associated with multiple ATG communication links, multiple satellite communication links and / or other types of communication links.

[0026] As illustrated, vehicle 105 may include one or more modems 115 configured to be compatible with multiple different communication standards utilized by airborne communication link 137, ATG communication link 147, and satellite communication link 157. For example, airborne communication link 137, ATG communication link 147, and satellite communication link 157 may utilize frequencies in their respective bands (e.g., K). a Bandwidth, K u The communication protocols (e.g., TDMA, GSM, CDMA, LTE, WiMAX, NR, Wi-Fi, etc.) of the frequency band, L-band, S-band, cellular band, AWS band, PCS band, unlicensed band, etc., and / or any other suitable wireless communication band are supported. In the illustrated embodiment, transceiver 109 may be adapted to communicate via one or more satellite communication links 157 (e.g., using modem 115 that supports satellite communication bands), and transceiver 108 may be adapted to communicate with base station 145 via communication link 147. Each of the plurality of modems 115 may be connected to at least one transceiver (e.g., the transceiver of transceiver 108 or transceiver 109) and / or configured to receive / transmit signals using any supported communication protocol of the airborne wireless access point 135. It should be understood that while certain communication protocols are more suitable for use in one of the airborne communication link 137, ATG communication link 147, or satellite communication link 157, this does not preclude the additional or alternative use of communication protocols for less suitable communication links.

[0027] As described, the vehicle 105 is also equipped with a network controller 120, which is operatively connected to the onboard wireless access point 135 and the modem 115. The network controller 120 supports communication outside the vehicle 105 via communication links 147 and 157 and manages the onboard network provided by the onboard communication link 137.

[0028] Generally, user equipment 110 can send and receive data via airborne communication link 137 through airborne wireless access point 135. User equipment 110 may include any mobile computing device, such as a smartphone, tablet computer, laptop computer, personal digital assistant, e-reader, smart glasses, smartwatch, or any other mobile computing device capable of wireless communication. The plurality of modems 115 can determine the addressing location outside vehicle 105 for some data transmitted by user equipment 110. Therefore, the plurality of modems 115 can forward and / or transmit this data to base station 145 (or forward and / or transmit to satellite ground station 150 via satellite communication link 157) for routing to the final destination of the data.

[0029] Base station 145 and satellite ground station 150 can be connected to network backbone 180, which may include, for example, a terrestrial cellular or radio network. Network backbone 180 can communicatively connect base station 145 and satellite ground station 150 to central server 160. Network backbone 180 can also connect to media server 170. Media server 170 stores content accessible via an onboard network to users carried by vehicle 105. Central server 160 may be associated with a provider of communication services for the vehicle and / or mobile devices carried by the vehicle. Central server 160 includes Link Service Profile (LSP) application 162, which can generate LSP 164, portions of LSP 164, and / or updates to LSP 164 stored therein.

[0030] Similarly, network controller 120 may also include an LSP application 122 that interfaces with the LSP application 162 of central server 160. In some embodiments, LSP application 122 stores a local version 124 of LSP 164. In these embodiments, LSP application 122 may generate a local LSP 124, portions of the local LSP 124, and / or updates to the local LSP 124. Additionally, LSP application 122 may route requests for data from LSP 164 of central server 160 and / or additionally obtain said data.

[0031] Figure 1B Additional details are provided for describing environment 100. In various embodiments, LSP 164 and / or local LSP 124 may include predicted or anticipated link rates during the journey of vehicle 105. For example, in the case where vehicle 105 corresponds to an aircraft, LSP 164 and / or local LSP 124 may include predicted link rates for links that will be communicatively connected to the vehicle during flight. LSP 164 and / or local LSP 124 may include predicted link rates for only one link, such as satellite communication link 157, ATG communication link 147, or airborne communication link 137, or may include predicted link rates for several links. If the link is bidirectional, the predicted link rate may include uplink and / or downlink rates. Furthermore, LSP 164 or local LSP 124 may include other predicted link characteristics and / or parameters, such as peak information rate, round-trip time or latency, status, utilization, planned operational downtime, or cost. Cost parameters can indicate how much it costs for a communications service provider to provide a link or for a user device 110 to access the link, in order to promote least-cost routing techniques.

[0032] Central server 160 can generate and store LSP 164. Central server 160 contains one or more processors 165. Processor 165 may contain a central processing unit (CPU), graphics processing unit (GPU), application-specific integrated circuit (ASIC), and / or any other type of computer processor. It should be understood that although Figure 1A-1B While the central server 160 is shown as a single entity, in other embodiments, the central server 160 may be multiple entities that operate in combination with each other. For example, in some embodiments, the central server 160 is partially or entirely implemented in a distributed computing environment, such as a cloud computing environment. In these embodiments, the processor 165 may physically reside in different hardware entities.

[0033] In addition to processor 165, the central server 160 in the illustrated embodiment also includes at least one memory 167 and input / output (I / O) circuitry 168, all of which are interconnected via address / data bus 166. It should be understood that memory 167 may include multiple random access memories (RAMs) and multiple program memories implemented as any type of memory, such as semiconductor memory, magnetically readable memory, or optically readable memory. Similarly, although I / O circuitry 168 is shown as a single block, it should be understood that I / O circuitry 168 may include several different types of I / O circuitry. For example, I / O circuitry 168 may include one or more transceiver circuits to facilitate communication with other devices in environment 100 via, for example, network backbone 180.

[0034] Memory 167 may store LSP 164 and instructions executable by processor 165 to form LSP application 162. LSP application 162 generates LSP 164 and processes requests for LSP 164 from other computing devices such as network controller 120. LSP application 162 generates and / or modifies LSP 164 based on data received from various data sources via I / O circuitry 168. Data sources may include historical link database 190, current link data source 192, and communication service provider data source 194.

[0035] The historical link database 190 contains historical link characteristics of one or more communication links during the historical routes of a vehicle. For example, a fleet of vehicles (which may or may not include vehicle 105) can travel multiple routes while communicatively connected to links such as links 137, 147, and 157. As the vehicles traverse routes, data on link quality at time and location during the route is collected, processed, and stored in the historical link database 190. The data can be collected by a computing device onboard the vehicle, such as a network controller 120 similar to vehicle 105, and transmitted to a ground-based computing device, such as a central server 160 and / or the historical link database 190. Historical link characteristics may include, for example, link rate, peak data rate, downlink rate, uplink rate, latency (e.g., round-trip time), link status, link cost, link downtime, and utilization.

[0036] Based on historical link characteristics and the route of vehicle 105, LSP application 162 can predict the link rates of links that will communicatively connect to vehicle 105 as the vehicle traverses the route. The planned route of the vehicle indicates the origin point, destination point, and scheduling locations in between. LSP application 162 can determine the link characteristics at various times and locations along the planned route of the vehicle. Based on historical link characteristics, LSP application 162 can determine historical link rates for those locations and / or times. Based on these historical link rates, LSP application 162 can predict what the link rates of links communicatively connecting to vehicle 105 will be at different times and / or locations during the planned route of the vehicle. In addition to link rates, LSP application 162 can also predict other link characteristics, such as peak information rate, latency, link status, link cost, utilization, etc. LSP application 162 can generate LSP 164 based on the predicted link rates. See below for reference. Figure 3 Discuss the example of LSP.

[0037] Current link data source 192 contains current link characteristics and information about conditions affecting those characteristics. One or more computing devices, such as network controller 120, ground base station 145 or 150, or central server 160, located on or outside the vehicle, can monitor the multiple links and collect data related to current characteristics. For example, current link data source 192 may contain the current link rate of links communicatively connected to vehicle 105 while vehicle 105 is traversing a route. Current link characteristics may also include current link status, current uplink and / or downlink rates, current peak data rate, current link usage, and current latency (e.g., round-trip time). Current link data source 192 may also contain changes to the planned route of the vehicle made before or during the journey due to traffic or weather conditions. Current link data source 192 may also contain information related to satellites, base stations, and other hardware supporting the link, such as indications of whether devices are experiencing malfunctions. Generally, current link data source 192 contains information that can indicate any real-time information related to the link, including anomalies. LSP application 162 uses data from current link data source 192 to predict link rate (and other link characteristics), updates historical link database 190, and / or updates LSP 164 directly before or simultaneously with vehicle 105 crossing the route.

[0038] The communication service provider data source 194 contains information associated with a communication service provider. For example, the communication service provider may offer different service options that a user (e.g., a passenger carried by vehicle 105) can purchase. These service options may correspond to different access levels for links with different service capabilities and prices. For example, the service options may have different average or peak link rates. The communication service provider data source may contain the price, maximum data rate, and types of permitted communication and / or capabilities associated with these different access levels. The LSP application 162 may enhance LSP 164 to indicate the predicted link rate at each offered access level.

[0039] For simplicity, Figure 1B The historical link database 190, the current link data source 192, and the communication service provider data source 194 are depicted as individual devices. However, it should be understood that multiple databases and / or data sources can constitute these elements. Multiple different computing devices can form database 190 and data sources 192, 194. In some embodiments, the functionality of database 190 and data sources 192, 194 can also be performed by computing devices with the same computing system, such as the computing system of a communication service provider. Furthermore, although Figure 1BAlthough not explicitly shown, it should be understood that network controller 120 may also have direct access to database 190 and data sources 192, 194. Network controller 120 may access resources 190, 192, and 194 to generate and / or update local LSP 124, as discussed below.

[0040] LSP application 162 can cause central server 160 to transmit the generated LSP 164 to network controller 120 located on vehicle 105. In some scenarios, LSP application 162 may not transmit the entire LSP 164 to network controller 120, but may instead transmit a portion of LSP 164 or an indication based on LSP 164. For example, central server 160 may transmit only the predicted link rate of a link, or it may transmit a qualitative description of the link rate, such as "high" or "low". As another example, central server 160 may transmit a portion of LSP 164 corresponding to an upcoming segment of the vehicle's route. Furthermore, central server 160 may transmit a description of the link rate based on an estimated application capability, such as "below the threshold for video streaming".

[0041] Central server 160 may transmit LSP 164 to network controller 120 carried by vehicle 105 before vehicle 105 begins to traverse its route or during the route. For example, if vehicle 105 is an aircraft, then central server 160 may transmit LSP 164 to network controller 120 simultaneously with or separately before the aircraft takes off from the airport gate. Central server 160 may transmit LSP 164 in response to a request received from network controller 120, or may push LSP 164 to network controller 120, for example, according to a scheduled push, without receiving a request. Furthermore, central server 160 may transmit updated LSP 164 to network controller 120 in response, for example, to receiving updated information from current link data source 192. For example, if LSP application 162 receives updated link information from current link data source 192 and updates LSP 164 accordingly, then LSP application 162 can cause central server 160 to send LSP 164 or an instruction based on LSP 164 to network controller 120.

[0042] As described, network controller 120 includes one or more processors 125, similar to processor 165 of central server 160. Processor 125 may include CPU, GPU, ASIC and / or any other type of computer processor. The network controller also includes at least one memory 127 and I / O circuitry 128, which may be interconnected with processor 125 via address / data bus 126, similar to central server 160. I / O circuitry 128 may receive information from (and transmit information to) other devices in environment 100 via internal communication link 137 and external communication links 147, 157.

[0043] Network controller 120 may store a local LSP 124 based on or equivalent to the received LSP 164. For example, after receiving LSP 164 from central server 160, the network controller may locally store LSP 164 as local LSP 124. The memory 127 of network controller 120 may contain instructions executable by processor 125 to form a local LSP application 122. Local LSP application 122 may format a request for information related to LSP 164 and cause network controller 120 to send the request to central server 160. For example, local LSP application 122 may send a request for LSP 164, receive LSP 164 in response, and locally store LSP 164 as local LSP 124. Local LSP application 122 may also locally generate and / or update local LSP 124 on vehicle 105. For example, local LSP application 122 can receive information about the current state of the link while the vehicle is moving from current link data source 192, and can predict link characteristics, including link speed, for the remainder of the journey. Local LSP application 122 can update local LSP 124 with predicted characteristics based on the current information. Local LSP application 122 can also receive and process requests from user device 110 for information related to LSP 164 or local LSP 124, as discussed below.

[0044] In some embodiments, network controller 120 may not store local LSP 124. In these embodiments, local LSP application 122 may receive requests for information related to LSP 164 from user device 110 and route these requests to central server 160. Local application 122 may then route information contained in the response from central server 160 to user device 110. Similarly, central server 160 may push information related to LSP 164 to network controller 120, and if user devices on vehicle 105 are communicatively connected to the onboard network, and in some scenarios if user device 110 has subscribed to updates regarding LSP 164, local LSP application 122 may distribute information to user devices 110 on vehicle 105.

[0045] While vehicle 105 traverses the route, user device 110 resides on vehicle 105. User device 110 is configured to execute one or more applications, such as application 132. Application 132 may be stored on one or more memories of user device 110 and executed by one or more processors of user device 110. In some embodiments, application 132 may be a web application or cloud service accessible from user device 110 via communication services provided by an onboard network. Application 132 may be, for example, a web browser, email application, messaging application, calendar application, audio player, video player, game application, etc. In some embodiments, application 132 may be an application provided by a communication service provider. The communication service provider application may allow the user to access the onboard network and purchase different service options. Application 132 may also allow the user to instruct user device 110 whether it should request information related to LSP 124 or 164.

[0046] User equipment 110 can receive information related to LSP 164 or local LSP 124 in various ways. Before being taken onto vehicle 105 (or after being taken onto vehicle 105 but before connecting to the onboard network), user equipment 110 can send a request to central server 160 for information related to LSP 164 and / or LSP 124. User equipment 110 can format the request according to an application programming interface (API) that may be provided by a communication service provider. The request can be for any information related to LSP 164 and / or local LSP 124, or it can be for specific information, such as the link rate at a specific time, or a prediction of when the link rate will be higher than a given threshold (e.g., a threshold for supporting video streaming). The request can indicate a specific application of the user equipment and a minimum available data rate for certain capabilities of the application, and can search for information about whether the predicted link rate is higher than the minimum available data rate. The request can also be for predicted link rates associated with different service options of the communication service provider. Furthermore, the request could be a subscription request for updates to LSP 164 and / or the local LSP 124. The central server 160 can indicate to the network controller 120 that a particular device has subscribed to updates to LSP 164 and / or the local LSP 124.

[0047] As an example, application 132 may provide an interface that allows a user to instruct user device 132 to subscribe to updates regarding LSP 164 and / or local LSP 124 for the user's upcoming trip. Application 132 may also automatically determine the user's upcoming trip on a vehicle and automatically send requests for information related to LSP 164 and / or local LSP 124 for the route used in the upcoming trip. Application 132 may display instructions to the user regarding the requested information. For example, application 132 may indicate the predicted link rates for various segments of the trip to the user. Application 132 may also indicate the predicted link rates for various service options from a communication service provider to the user, enabling the user to select service options that will support the capabilities the user plans to rely on during the trip.

[0048] A user associated with user device 110 may also utilize another device, such as a check-in kiosk or computer, to request information related to LSP 164 and / or local LSP 124 prior to the trip. For example, when purchasing a ticket for the trip or when checking in, a user may provide a phone number or other identifier of user device 110. The check-in kiosk or computer may then issue a request to a central server 160 to send information related to LSP 164 to user device 110.

[0049] User device 110 may also transmit requests for LSP 164 and / or local LSP 124 while simultaneously located on vehicle 105. User device 110 may, in response to connection to the onboard network, transmit a request to network controller 120 for information relating to LSP 164 and / or local LSP 124, similar to the request transmitted to central server 160 discussed above. User device 110 may format the request according to an API that may be provided by a communication service provider. Network controller 120 may respond with information based on local LSP 124. In some scenarios, such as when network controller 120 does not store local LSP 124, network controller 120 may transmit a request for information relating to LSP 164 to central server 160 and respond to user device 110 with information received from central server 160.

[0050] A request sent from user device 110 to network controller 120 can be similar to a request sent from user device 110 to central server 160. The request can be for any information related to LSP 164 or local LSP 124, such as current information contained in LSP 164 or local LSP 124. The request can also be a subscription request for updates to LSP 164 or local LSP 124. User device 110 can send a request containing the subscription request to network controller 120 in response to detecting that user device 110 is on a vehicle. For example, application 132 can be associated with a communications service provider and detect a specific service set identifier (SSID) of the onboard network. Application 132 can also receive updates on the flight status of the vehicle (e.g., airport gate port status, gate opening, or, in the case of an aircraft, the vehicle ascending to over 10,000 feet) and can send a request for the updated flight status in response to detecting such updates. Similarly, user device 110 may send a request for information containing a subscription request to network controller 120 in response to connection to the onboard network.

[0051] In response to a request from user equipment 110, central server 160 or network controller 120 transmits information related to local LSP 124 or LSP 164 to user equipment 110. Central server 160 or network controller 120 can format the response according to an API that may be provided by a communication service provider. Furthermore, network controller 120 or central server 160 may broadcast information based on local LSP 124 or LSP 164 to user equipment 110 connected to the onboard network, or may only broadcast information to user equipment 110 that has sent a subscription request to network controller 120 or central server 160. Network controller 120 or central server 160 may periodically broadcast information as the vehicle moves from its origin to its destination (e.g., at time intervals, or when the vehicle reaches certain states, such as flight status in the case of an aircraft). Network controller 120 or central server 160 may broadcast information in response to the detection of an update to local LSP 124 or LSP 164, such as an update due to a changed route or network anomaly. In some scenarios, the central server 160 can update LSP 164 and can send the update indication to the network controller 120. In response to receiving the updated LSP 164, the network controller 120 can update the local LSP 124 and send the updated local LSP 124 indication to the subscriber device.

[0052] As mentioned above, the information transmitted to user equipment 110 related to LSP 164 or local LSP 124 may be an indication based on LSP 164 or local LSP 124 rather than the entire LSP 164 or local LSP 124. The indication based on LSP 164 or local LSP 124 may include information reflecting the data contained within LSP 164 or local LSP 124. For example, the indication may be the current or predicted link rate, uplink rate, downlink rate, peak information rate, or latency (e.g., round-trip time). As another example, the indication may indicate whether the predicted link rate is higher than a given threshold, such as the minimum available data rate for application 132. The indication may relate to a specific application and may indicate a specific capability that is predicted to be unavailable at certain times during the route. The indication may also be a general prediction not related to a specific application but related to general capabilities such as video streaming. For example, the indication may include a prediction that no video service will be available during a specific time range. The indication can also be the current or predicted status of the link, such as "predicted airborne network will be disconnected" or "predicted airborne network will be connected within 10 minutes".

[0053] In response to receiving information relating to LSP 164 or local LSP 124, an application executing on user device 110, such as application 132, may modify its behavior in a way that optimizes the performance of the application and user device 110. (See reference) Figures 4A-4B Discuss the instance behavior modifications that can be made to the application.

[0054] refer to Figure 2-3 These diagrams illustrate instance route 201 and instance LSP 364 for route 201. Figure 2 The diagram shows a vehicle 205 (which may be...) Figure 1A-1B The vehicle 205 is in an environment 200, moving along route 201 while communicating via one or more links provided by multiple satellites 204, 206, and 208. Satellites 204, 206, and 208 may be part of a satellite communication system providing satellite communication links to the vehicle 205, such as… Figure 1A-1B Satellite communication link 157. In some cases, vehicle 205 can travel exactly along the scheduled route 201 from origin point 202 to destination point 210. In other cases, the actual route may differ from the planned route 201 because vehicle 205 may deviate from its planned route 201 due to current conditions such as weather and / or traffic. Route 201 can be shown at times t1-t2 as indicated by axis 216. 10 Passing through the geographical location x1-x shown by axis 214 10 At time t2, for example, vehicle 205 is dispatched to location x2.

[0055] As vehicle 205 moves along route 201, the quality of the satellite communication link can vary based on the location of vehicle 205 and the time at which vehicle 205 is located. For example, from time t1 to t3, vehicle 205 is within the coverage area of ​​satellite 204. At time t4, vehicle 205 is outside the coverage area provided by the beams of satellites 204, 206, and 208. From time t5 to t8, vehicle 205 changes from the coverage area of ​​satellite 206 to the coverage area of ​​satellite 208, and then arrives at destination 210 at time t9.

[0056] Also refer to Figure 3 The example LSP 364 is described, which can be stored at a central server, for example... Figure 1A-1B The LSP 164, or stored at the network controller, for example Figure 1A-1B The local LSP 124. LSP 364 can be included. Figure 2The LSP 364 describes the predicted link characteristics of one or more communication links during the process of route 201. The LSP 364 may be based on historical link characteristics corresponding to route 201 (e.g., historical link characteristics received from historical link database 190). If vehicle 205 has an upcoming trip or is currently traveling along route 201, then the LSP 364 may contain entries containing predicted link rates based on current information retrieved from current link data source 192. The depicted LSP 364 contains entries associated with one link, but in other embodiments, the LSP 364 may contain entries corresponding to multiple links.

[0057] In the depicted embodiment, LSP 364 may correspond to a data table 302 with entries including time 325, events corresponding to the time 326, predicted link rate 327, and cost 328. Although Figure 3 While LSP 325-328 are described, LSP 364 may include additional predictive information related to the links communicatively connected to vehicle 205. For each time period 325, LSP 364 may include a description of the predicted events 326 occurring at that time, such as "flight start," "in flight," "leaving coverage," "entering coverage," "beam switching start," "beam switching end," and "flight end." Furthermore, for each time period 325, LSP 364 includes the link rate 327 (e.g., megabits per second (Mbps)) and cost 328. The cost may correspond to a decimal or similar quantitative measure of the relative cost of providing the link. Alternatively or additionally, the cost may be a qualitative description, such as "low" or "high." The predicted cost of the link corresponds to how much it costs a communication service provider to provide the link to vehicle 205 and / or how much it costs a user device to access the link, thereby achieving minimum cost routing. This can be particularly useful in embodiments where LSP 364 includes data describing multiple links. If the link rate is zero at a specific time (e.g., time t3 when vehicle 205 has left the coverage area), then the cost can be NA because there is actually no link available at that time.

[0058] User device 110 (e.g.) Figure 1A-1B Applications on user device 110 (e.g.) Figure 1B Application 132) can be used as described above regarding Figure 1A-1BLSP 364 can be accessed in any of the ways described in LSP 124 and / or 164. In response to receiving LSP 364, a portion of LSP 364, or an instruction based on LSP 364, the user device and / or the application executing thereon can take various actions. As an example, the application can modify its behavior while the vehicle is moving from its origin point to its destination point or before the vehicle begins route 201. In one scenario, LSP 364 may indicate that the predicted link rate at a specific future time is lower than the minimum available data rate for the application or a specific capability of the application. In response, the application can take appropriate steps to optimize its behavior given a low link rate. For this purpose, the application can pre-download or cache content before the start of route 201 (e.g., before time t1) or during route 201 when the link service profile indicates that the link rate will be higher than the application's minimum available data rate (e.g., if the application's minimum available data rate is 6 Mbps, then at times t1-t3 and t8-t9). By caching data, applications can prepare for predicted low link rates and continue to provide content-related services even during periods corresponding to low link rates. Similarly, based on LSP 364, applications can choose not to attempt to perform downloads at specific times given a predicted link rate (e.g., during times t4-t7 when the link rate is 0-5 Mbps). Alternatively, applications can adjust the rate at which they perform downloads based on the predicted link rate.

[0059] Applications can also present alerts, warnings, and / or notifications to users, based on LSP 364, informing them that one or more of the application's capabilities are unavailable or will be unavailable during Route 201. Notifications may contain information contained in LSP 364 or predictive capabilities of the application based on LSP 364. For example, a notification may indicate that the application's capabilities will be unavailable or interrupted during Route 201. See also... Figure 4A The user device 410 executing the application is shown (e.g., Figure 1A-1B The user device 410 is an instance interface. User device 410 can receive an indication based on LSP 364, including the predicted link rate. For example, the application can determine that the predicted link rate is below a threshold for streaming video. In response, the application can present an alert 402 via the graphical user interface (GUI) of user device 410, indicating that video capability will be unavailable during a specific time period on route 201 corresponding to the low predicted link rate.

[0060] In addition to notifications, applications can also alter how various GUIs present information to users. For example, an application can change the options displayed to the user to indicate that an application option is unavailable at a given predicted link rate. An application can gray out or hide unavailable or blocked options. Alternatively, an application can simply not offer options that would require a data rate higher than the predicted link rate. Additionally, an application can highlight or further indicate application capabilities that are allowed or will be allowed based on the predicted link rate. See also [reference needed]. Figure 4B This shows an instance interface of the user device 410 associated with the application. The application can be a messaging application with multiple capabilities and can present corresponding user-selectable options, such as text messaging option 406, voice call option 408, and video call option 410. Based on the indication received from LSP 364, the application can determine that video calling will be unavailable during route 201 and can correspondingly gray out video call option 410.

[0061] As another example, the application could be a video streaming application, such as Netflix®, or one that streams data from a media server (e.g., Figure 1A-1B The media server 170 streams content to other applications on the user device. The applications can request information related to LSP 364 from the network controller of vehicle 205. In response, the network controller can provide the predicted link rate of LSP 364. Based on this indication, the applications can determine when to download video content to provide uninterrupted video service to the user. For example, if the user has requested a movie, the application can download the movie completely when the link user device 410 has a predicted link rate high enough to properly support the download of video content. When vehicle 205 enters an area corresponding to a low predicted link rate, the application will not need to access any new content, and video functionality will still be available to the user.

[0062] As another example, the application could be a calendar application. Based on LSP 364 guidelines, the application can determine that internet service may be unavailable during a scheduled online meeting. The application can then display notifications to users and / or other meeting participants that the meeting will be unavailable, start late, or be interrupted.

[0063] As another example, an application can modify its behavior to optimize link costs. For instance, if the received LSP 364-based indication suggests that the link is more expensive at time t2 than at time t1, then the application can perform the download at time t1 instead of time t2.

[0064] In various implementations, the application can modify multiple behaviors based on the instructions received from LSP 364. For example, the application can gray out a capability and display a notification to the user. Furthermore, multiple applications running on user device 410 can modify their behavior in light of LSP 364. Each application can modify its corresponding behavior in different ways.

[0065] Figure 5 This is a flowchart illustrating an example method 600 for modifying application performance based on link conditions, the method being implemented in... Figure 1A-1B Environment 100 and / or Figure 2 In environment 200. More specifically, method 500 can be, for example, located in a vehicle (e.g., Figure 1A-1B Land locations outside of the vehicles 105 or 205 respectively (e.g., Figure 1A-1B The central server 160) of the central server, the network controller located on the vehicle (e.g., Figure 1A-1B The network controller 120) or the central server combined with the network controller can perform this action.

[0066] Method 500 begins at box 502, whereby the mobile device carried by the vehicle (e.g., Figure 1A-1B User equipment 110 Figures 4A-4B The computing device (e.g., network controller and / or central server) of the system providing communication services (user device 410) predicts the corresponding link rate of at least one of multiple links. As the vehicle travels along a route (e.g., ... Figure 2 As the vehicle moves from its origin point to its destination along route 201, the multiple links deliver data in and out of the vehicle. These multiple links may include satellite communication links (e.g., Figure 1A-1B Satellite communication link 157), ATG communication link (e.g., Figure 1A-1B ATG communication link 147), or airborne communication link (e.g., Figure 1A-1B The airborne communication link 137). At least one of the plurality of links may, for example, support Long Term Evolution (LTE) communication. The computing device bases its analysis on historical link characteristics (e.g., from...). Figure 1B (The historical link database 190 is received) predicts link rates. Historical link characteristics can be the characteristics of multiple links during the historical routes of multiple modes of transportation.

[0067] In some scenarios, the computing device may also predict or update the predicted link rate based on the current link characteristics of the plurality of links (e.g., the link characteristics of the plurality of links while a vehicle is moving along a route). The computing device may also predict additional parameters of the at least one link in addition to the link rate based on historical and / or current link characteristics. Additional parameters may include peak information rate, latency (e.g., round-trip time), status, or cost.

[0068] At box 504, the computing device generates a Link Service Profile (LSP) for the vehicle based on the predicted corresponding link rate of the at least one link and the route of the vehicle between the origin and destination points. Figure 1A-1B LSP 164 or local LSP 124, or Figure 3 LSP 364). The LSP may contain predictions of the corresponding link rate (e.g., Figure 3 The link rate is 327), and may also include additional prediction parameters (e.g., link rate ... Figure 3 The cost is 328).

[0069] At box 506, the computing device receives a request from the mobile device for information related to an LSP. The request may be for an LSP stored at the computing device and / or a request to subscribe to future transmissions associated with the LSP. The request may be received from the mobile device before it boards the vehicle or while it is on board the vehicle.

[0070] At box 508, the computing device transmits an LSP-based instruction to the mobile device, thereby causing the behavior of the application executing on the mobile device to be modified based on the LSP as the vehicle traverses the route. For example, the application may display... Figures 4A-4B The interface is depicted in the diagram. A computing device can format instructions according to an API and transmit the formatted instructions to a mobile device. If, for example, the computing device is a central server, then the central server can transmit LSP-based instructions to a second computing device located on a vehicle, such as a network controller. This transmission causes the second computing device to transmit LSP-based instructions to the mobile device. The instructions may include, for example, a predicted link rate for the at least one link or other predicted characteristics of the at least one link.

[0071] If the request received at box 506 is a request to subscribe to future transmissions related to an LSP, then at box 506, the computing device can periodically transmit LSP-based instructions to the mobile device (e.g., at time intervals, or when the vehicle reaches certain states, such as the flight state in the case of an aircraft) while the vehicle is moving from the origin point to the destination point.

[0072] Method 500 may further include receiving an indication of current conditions associated with the plurality of links, the current conditions corresponding to a change in the route of the vehicle or the current link characteristics of the plurality of links. The computing device may update the predicted link rate (and other predicted link characteristics) and correspondingly update the LSP to reflect the updated predicted link rate. In response to updating the LSP, the computing device may transmit an indication based on the updated LSP to the mobile device. In some scenarios, the computing device may broadcast the updated LSP to mobile devices connected to an airborne network, or may broadcast the updated LSP to mobile devices from which the computing device receives subscription requests.

[0073] Figure 6 This is a flowchart illustrating an example method 600 for modifying application performance based on link conditions, the example method being usable by a mobile device (e.g., Figure 1A-1B User equipment 110 Figures 4A-4B (User device 410) is implemented.

[0074] Method 600 begins at box 602, where the moving device will target the LSP (e.g., Figure 1A-1B LSP 164 or local LSP 124, or Figure 3 The request for information related to LSP 364 was sent to the vehicle (e.g., Figure 1A Transportation 105 or Figure 2 The computing device associated with the vehicle 205) Figure 1A-1B The network controller 120 or central server 160). The LSP includes a predictive corresponding link rate for at least one of a plurality of links used to deliver data to and from the vehicle as it moves from its origin to its destination. The plurality of links may include satellite communication links (e.g., Figure 1A-1B Satellite communication link 157), ATG communication link (e.g., Figure 1A-1B ATG communication link 147), or airborne communication link (e.g., Figure 1A-1B (Airborne communication link 137). The mobile device can format the request according to the API before sending the request to the computing device. In addition, the mobile device can send the request before or at the same time as the mobile device is on the vehicle.

[0075] Furthermore, the mobile device can detect that it is on a vehicle (e.g., by detecting the SSID of the onboard network) and establish a connection with at least one of the plurality of links. In response to establishing a connection with the at least one link, the mobile device can send a request for information related to the link service profile.

[0076] At box 604, the mobile device receives an LSP-based instruction from the computing device. At box 606, based on the received instruction, the mobile device modifies an application running on the mobile device (e.g., ...) while the mobile device is mounted on a vehicle. Figure 1B The behavior of application 132.

[0077] Mobile devices can modify the behavior of applications in various ways. For example, a mobile device can modify the downloading of content to the mobile device via the application based on an LSP (e.g., by blocking the download, changing the download rate, or pre-downloading content when the indication indicates that the predicted link rate is sufficient to support the download). A mobile device can modify how the application is displayed on the GUI (e.g., by indicating on the GUI that the application's capability is unavailable, graying out the portion of the GUI corresponding to the unavailable capability, or causing the application to display a notification based on an LSP indicating at least one of the information contained in the LSP or the application's predicted capability). A mobile device can modify the application's behavior while the vehicle is moving from one origin point to another.

[0078] Figure 7 A block diagram of a user device 710 implementing the techniques disclosed herein for modifying application performance is shown, the user device being, for example... Figure 1A-1B User devices 110 and 410 in user devices 4A-4B. User device 710 may include, for example, one or more central processing units (CPUs) or processors 752, and one or more buses or hubs 753 connecting processor 752 to other elements of user device 710, such as volatile memory 754, non-volatile memory 755, display controller 756, and I / O controller 757. Volatile memory 754 and non-volatile memory 755 may each include one or more non-transitory, tangible computer-readable storage media, such as random access memory (RAM), read-only memory (ROM), flash memory, bio-memory memory, hard disk drive, digital versatile optical disc (DVD) drive, etc.

[0079] In one embodiment, memory 754 and / or memory 755 may store instructions 758 executable by processor 752. In a user device configured to modify application performance based on link conditions, the instructions may be instructions to send a request for information relating to an LSP (e.g., LSP 124, LSP 124, or LSP 364) to a computing device (e.g., to network controller 120) and receive LSP-based indications. For example, the instructions may configure the user device to format requests according to an API. The instructions may also include instructions for modifying application behavior based on the received LSP indications.

[0080] In one embodiment, the display controller 756 can communicate with the processor 752 to cause information to be displayed on a connected display device 759. In one embodiment, the I / O controller 757 can communicate with the processor 752 to transmit information and commands to / from a user interface 760, which may include a mouse, keyboard or keypad, touchpad, click wheel, lights, speakers, microphone, etc. In one embodiment, at least a portion of the display device 759 and the user interface 760 are combined in a single integrated device, such as a touchscreen. Additionally, data or information can be transmitted to and from the user device 710 via a network interface 770. In some embodiments, the user device 710 may include more than one network interface 770, such as a wireless interface and a wired interface.

[0081] Additional considerations

[0082] Throughout this specification, multiple instances can implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are described and presented as separate operations, one or more of these individual operations can be performed in parallel, and are not required to be performed in the order described. The structure and functionality presented as a single component in an instance configuration can be implemented as a composite structure or component. Similarly, the structure and functionality presented as a single component can be implemented as a single component. These and other changes, modifications, additions, and improvements fall within the scope of the subject matter herein.

[0083] Additionally, some embodiments described herein include logic or a number of routines, subroutines, application programs, or instructions. These may constitute software (e.g., code embodied on a machine-readable medium) or hardware. In hardware, routines, etc., are tangible units capable of performing certain operations and may be configured or arranged in a certain manner. In exemplary embodiments, one or more computer systems (e.g., standalone consumer or server computer systems) or one or more hardware modules of a computer system (e.g., processors or a group of processors) may be configured as hardware modules by software (e.g., applications or application portions) that operate to perform certain operations as described herein.

[0084] In various embodiments, the hardware module may be implemented mechanically or electronically. For example, the hardware module may include dedicated circuitry or logic (e.g., a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)) permanently configured to perform certain operations. The hardware module may also include programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) temporarily configured by software to perform certain operations. It should be understood that the decision to implement the hardware module mechanically, in a dedicated and permanently configured circuit system, or in a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

[0085] Therefore, the term "hardware module" should be understood to encompass tangible entities, referring to entities that are physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or perform certain operations described herein. Consider hardware modules as implementations of temporary configurations (e.g., programming), where at any given time, it is not necessary to configure or initialize each hardware module. For example, when hardware modules include a general-purpose processor configured using software, the general-purpose processor can be configured as different hardware modules at different times. Software can therefore configure the processor, for example, to constitute a specific hardware module at one time and different hardware modules at different times.

[0086] Hardware modules can provide information to and receive information from other hardware modules. Therefore, the described hardware modules can be considered communicatively coupled. When multiple such hardware modules exist simultaneously, communication can be achieved through signal transmission connecting the hardware modules (e.g., via appropriate circuitry and buses). In embodiments where multiple hardware modules are configured or instantiated at different times, communication between such hardware modules can be achieved, for example, by storing and retrieving information from memory structures accessed by the multiple hardware modules. For example, one hardware module can perform an operation and store the output of such operation in its communicatively coupled memory product. Another hardware module can then subsequently access the memory product to retrieve and process the stored output. Hardware modules can also initiate communication with input or output products and can operate on resources (e.g., collections of information).

[0087] The various operations of the example methods described herein can be performed at least in part by one or more processors, which may be temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, these processors may constitute processor-implemented modules that operate to perform one or more operations or functions. In some example embodiments, the modules mentioned herein may include processor-implemented modules.

[0088] Similarly, the methods or routines described herein may be implemented at least in part by a processor. For example, at least some of the operations of the methods may be executed by one or more processors or processor-implemented hardware modules. Specific performance characteristics of the operations may be distributed across one or more processors, residing not only within a single machine but also deployed across multiple machines. In some exemplary embodiments, one or more processors may reside in a single location (e.g., in a home environment, office environment, or server cluster), while in other embodiments, the processors may be distributed across multiple locations.

[0089] The specific performance characteristics of an operation can be distributed across one or more processors, residing not only within a single machine but also deployed across multiple machines. In some exemplary embodiments, one or more processors or processor-implemented modules may be located in a single geographic location (e.g., a home environment, an office environment, or a server cluster). In other exemplary embodiments, one or more processors or processor-implemented modules may be distributed across multiple geographic locations.

[0090] Unless otherwise specified, the use of terms such as “processing,” “operation,” “calculation,” “determining,” “presenting,” “displaying,” etc., in this document may refer to the actions or processes of a machine (e.g., a computer) that manipulates or transforms data in physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0091] As used herein, any reference to "an embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrase "in an embodiment" in various places in the specification does not necessarily refer to the same embodiment.

[0092] Some embodiments may be described using the expressions “coupled” and “connected” and their derivatives. For example, the term “coupled” may be used to describe some embodiments to indicate that two or more elements are in direct physical or electrical contact. However, the term “coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other. In this case, the embodiments are not limited.

[0093] As used herein, the terms “comprising,” “including,” “containing,” “having,” “possessing,” or any other variations thereof inherently cover non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, “or” means inclusive or not exclusive or. For example, conditions A or B are satisfied by any of the following: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

[0094] Additionally, the use of "a / an" is used to describe elements and components of the embodiments described herein. This is merely for convenience and to provide a general description. This description and the appended claims should be understood to include one or at least one, and unless explicitly stated otherwise, the singular also includes the plural.

[0095] This detailed description should be interpreted as exemplary only and does not describe every possible embodiment, as describing every possible embodiment would be impractical, if not impossible. Many alternative embodiments can be implemented using current technology or technology developed after the filing date of this application.

[0096] Furthermore, although the foregoing text provides detailed descriptions of many different embodiments, it should be understood that the scope of this patent is defined by the words of the claims set forth at the end of this patent. The detailed descriptions should be interpreted as exemplary only and do not describe every possible embodiment, as it would be impractical to describe every possible embodiment if not impossible. Numerous alternative embodiments may be implemented using current technology or technology developed after the date of this patent application, and these embodiments will still fall within the scope of the claims. By way of example and not limitation, the disclosure herein contemplates at least the following aspects:

[0097] 1. A method for modifying application performance in view of link conditions, comprising: a computing device of a system providing communication services to a mobile device carried by a vehicle predicting a corresponding link rate of at least one of a plurality of links for delivering data to and from the vehicle while the vehicle is moving from a point of origin to a point of destination, wherein the prediction is based on historical link characteristics; generating a link service profile of the vehicle by the computing device based on the predicted corresponding link rate of the at least one link and a route of the vehicle between the point of origin and the point of destination; receiving from the mobile device a request for information related to the link service profile; and transmitting to the mobile device an instruction based on the link service profile, thereby causing the behavior of an application executing on the mobile device to be modified based on the link service profile while the vehicle is traversing the route.

[0098] 2. The method according to the foregoing aspect, wherein the computing device is located on the vehicle.

[0099] 3. The method according to aspect 1, wherein the computing device is located on land outside the vehicle.

[0100] 4. The method according to any combination of the foregoing aspects, wherein predicting the corresponding link rate of the at least one link further comprises: predicting the corresponding link rate based on the current link characteristics of the plurality of links.

[0101] 5. The method according to any combination of the foregoing aspects, wherein the historical link characteristics are characteristics of the plurality of links during the historical routes of the plurality of vehicles.

[0102] 6. The method according to any combination of the foregoing aspects, wherein transmitting the instruction based on the link service profile to the mobile device comprises: transmitting the instruction based on the link service profile to a second computing device located on the vehicle; wherein transmitting the instruction based on the link service profile causes the second computing device to transmit the instruction based on the link service profile to the mobile device.

[0103] 7. The method according to any combination of the foregoing aspects, wherein transmitting the instruction based on the link service profile comprises: formatting the instruction based on the link service profile according to an application programming interface (API); and transmitting the formatted instruction to the mobile device.

[0104] 8. The method according to any combination of the foregoing aspects, wherein the indication includes the predicted corresponding link rate of the at least one link.

[0105] 9. The method according to any combination of the foregoing aspects, wherein the request for information is a request to subscribe to future launches associated with the link service profile.

[0106] 10. The method according to the foregoing aspect, wherein transmitting the indication based on the link service profile to the mobile device comprises: periodically transmitting the indication based on the link service profile to the mobile device while the vehicle is moving from the origin point to the destination point.

[0107] 11. The method according to aspect 9, further comprising: receiving at the computing device an indication of current conditions related to the plurality of links, the current conditions corresponding to at least one of a change in the route of the vehicle or current link characteristics of the plurality of links; updating the predicted corresponding link rate by the computing device based on the received indication of the current conditions; updating the link service profile by the computing device based on the predicted corresponding link rate; and, in response to updating the link service profile, transmitting an indication based on the updated link service profile to the mobile device.

[0108] 12. The method according to any combination of the foregoing aspects, wherein receiving the request for information related to the link service profile comprises: receiving the request for information related to the link service profile from the mobile device while the mobile device is carried on the vehicle.

[0109] 13. The method according to any combination of aspects 1 to 11, wherein receiving the request for information relating to the link service profile includes: receiving the request for information relating to the link service profile before the mobile device is carried on the vehicle.

[0110] 14. The method according to any combination of the foregoing aspects, wherein the at least one of the plurality of links is: a satellite communication link, an air-to-ground communication link, or a link of a network carried by the vehicle.

[0111] 15. The method according to any combination of the foregoing aspects, wherein at least one of the plurality of links supports Long Term Evolution (LTE) communication.

[0112] 16. The method according to any combination of the foregoing aspects, further comprising: predicting one or more parameters of the at least one link based on the historical link characteristics, the one or more parameters including at least one of the following: peak information rate, round-trip time, status, or cost; and wherein generating the link service profile comprises: generating the link service profile based on the one or more parameters of the at least one link.

[0113] 17. A computer-implemented method executed by a mobile device to modify application performance in view of link conditions, the method comprising: sending a request to a computing device associated with a vehicle for information related to a link service profile, the link service profile including predicted corresponding link rates for delivering data to and from at least one of a plurality of links of the vehicle while the vehicle is moving from a point of origin to a point of destination; receiving an instruction based on the link service profile from the computing device; and modifying the behavior of an application executed on the mobile device while the mobile device is carried on the vehicle based on the instruction based on the link service profile.

[0114] 18. The method according to the foregoing aspect further includes: formatting the request for information based on the link service profile according to an application programming interface (API) before sending the request to the computing device.

[0115] 19. The method according to any combination of aspects 17 to 18, wherein the prediction of the corresponding link rate is based on historical link characteristics.

[0116] 20. The method according to any combination of aspects 17 to 19, wherein transmitting the request for information based on the link service profile comprises: transmitting the request while the mobile device is carried on the vehicle.

[0117] 21. The method according to any combination of aspects 17 to 20, wherein modifying the behavior of the application comprises: modifying the download of content to the mobile device via the application based on the link service profile by at least one of the following: blocking the download, changing the download rate, or caching the downloaded content.

[0118] 22. The method according to any combination of aspects 17 to 21, wherein modifying the behavior of the application includes: modifying the way the application is displayed on a graphical user interface (GUI) based on the link service configuration file.

[0119] 23. The method according to the foregoing aspect, wherein modifying the way the application is displayed includes: indicating on the GUI that the application's capabilities are unavailable.

[0120] 24. The method according to the foregoing aspect, wherein indicating that the capability of the application is unavailable includes: graying out a portion of the GUI corresponding to the unavailable capability.

[0121] 25. The method according to aspect 22, wherein modifying the way the application displays includes: causing the application to display a notification indicating at least one of information contained in the link service configuration file or the predictive capabilities of the application, based on the link service configuration file.

[0122] 26. The method according to any combination of aspects 17 to 25, wherein modifying the behavior of the application comprises: modifying the behavior of the application while the vehicle is moving from the point of origin to the point of destination.

[0123] 27. The method according to any combination of aspects 17 to 26, wherein transmitting the request for information comprises: detecting that the mobile device is carried on the vehicle; and establishing a connection with at least one of the plurality of links; and, in response to establishing the connection with the at least one link, transmitting the request for information related to the link service profile.

[0124] 28. A non-transitory computer-readable storage medium storing processor-executable instructions, which, when executed, cause one or more processors to: send a request to a computing device associated with a vehicle for information related to a link service profile, the link service profile including predicted corresponding link rates for delivering data to and from at least one of a plurality of links of the vehicle while the vehicle is moving from a point of origin to a point of destination; receive instructions from the computing device based on the link service profile; and modify the behavior of an application executing on the mobile device while the mobile device is carried on the vehicle, based on the instructions based on the link service profile.

Claims

1. A method for modifying application performance based on link conditions, comprising: A network controller of a system providing communication services to mobile devices on a vehicle predicts the corresponding link rate of at least one of a plurality of external links, wherein the network controller is located on the vehicle, the plurality of external links are used to deliver data to and from the network controller as the vehicle moves from a point of origin to a point of destination, the network controller manages an onboard network provided to the mobile devices on the vehicle by an onboard radio access point and the network controller is connected to the onboard radio access point, wherein the prediction is based on historical link characteristics; The network controller generates a link service profile for the vehicle based on the predicted link rate of the at least one external link and the route of the vehicle between the origin point and the destination point; The network controller receives a request from the mobile device for information related to the link service profile. as well as The network controller sends an instruction to the mobile device based on the link service profile, wherein, in response to receiving the instruction, the behavior of an application executing on the mobile device based on the link service profile is modified when the vehicle traverses the route and the mobile device is connected to the onboard network.

2. The method of claim 1, wherein predicting the corresponding link rate of the at least one external link further comprises: The corresponding link rate is predicted based on the current link characteristics of the multiple external links.

3. The method according to claim 1, further comprising: The network controller formats the instructions based on the link service configuration file according to the application programming interface (API).

4. The method of claim 1, wherein the request for information is a request to subscribe to future launches associated with the link service profile.

5. The method of claim 4, wherein transmitting the indication based on the link service profile to the mobile device comprises: As the vehicle moves from the origin point to the destination point, the instructions based on the link service profile are periodically transmitted to the mobile device.

6. The method of claim 4, further comprising: The network controller receives an indication of current conditions related to the plurality of external links, the current conditions corresponding to at least one of the change of the route of the vehicle or the current link characteristics of the plurality of external links; The network controller updates the predicted corresponding link rate based on the indication received from the current conditions; The network controller updates the link service configuration file based on the predicted link rate. as well as In response to updating the link service profile, an instruction based on the updated link service profile is transmitted to the mobile device.

7. The method according to claim 1, wherein the at least one of the plurality of external links is: a satellite communication link, or an air-to-ground communication link.

8. The method of claim 1, further comprising: Based on the historical link characteristics, one or more parameters of the at least one external link are predicted, said one or more parameters including at least one of the following: peak information rate, round-trip time, status, or cost, wherein generating the link service profile includes: The link service configuration file is generated based on one or more parameters of the at least one external link.

9. A method performed by a mobile device to modify application performance based on link conditions, the method comprising: A request for information related to a link service profile is sent to a network controller associated with the vehicle. The link service profile contains predicted corresponding link rates for delivering data to and from at least one of a plurality of external links to the network controller while the vehicle is moving from origin to destination. The prediction of the corresponding link rate of the at least one of the plurality of external links and the generation of the link service profile are performed by the network controller, which manages the onboard network on the vehicle, which is provided by an onboard radio access point to the mobile device carried by the vehicle, and the network controller is connected to the onboard radio access point. Receive an instruction based on the link service configuration file from the network controller; and In response to receiving the instruction, the behavior of the application running on the mobile device is modified when the mobile device is carried on the vehicle and connected to the onboard network.

10. The method of claim 9, further comprising: The request for information based on the link service profile is formatted according to the application programming interface (API) before being sent to the network controller.

11. The method of claim 9, wherein modifying the behavior of the application comprises: Based on the link service profile, modify the content download to the mobile device via the application by at least one of the following: blocking the download, changing the download rate, or caching the downloaded content.

12. The method of claim 9, wherein modifying the behavior of the application comprises: The way the application is displayed on the graphical user interface (GUI) is modified based on the link service configuration file.

13. The method of claim 12, wherein modifying the way the application is displayed includes: The GUI indicates that the application's capabilities are unavailable.

14. The method of claim 12, wherein modifying the way the application is displayed includes: Based on the instruction, the application displays a notification indicating at least one of the information contained in the link service configuration file or the application's predictive capabilities.

15. The method of claim 9, wherein sending the request for information comprises: The mobile device is detected on the vehicle; as well as Establish a connection with the airborne network; In response to establishing the connection with the airborne network, the request for information related to the link service profile is transmitted.

16. A non-transitory computer-readable storage medium storing processor-executable instructions, which, when executed, cause one or more processors of a mobile device to: A request for information related to a link service profile is sent to a network controller associated with the vehicle. The link service profile contains predicted corresponding link rates for delivering data to and from at least one of a plurality of external links to the network controller while the vehicle is moving from origin to destination. The prediction of the corresponding link rate of the at least one of the plurality of external links and the generation of the link service profile are performed by the network controller, which manages the onboard network on the vehicle, which is provided by an onboard radio access point to the mobile device carried by the vehicle, and the network controller is connected to the onboard radio access point. Receive an instruction based on the link service configuration file from the network controller; and In response to receiving the instruction, the behavior of the application running on the mobile device is modified when the mobile device is carried on the vehicle and connected to the onboard network.

17. The non-transitory computer-readable storage medium of claim 16, wherein the instructions, when executed, cause one or more processors of the mobile device to: The request for information based on the link service profile is formatted according to the application programming interface (API) before being sent to the network controller.

18. The non-transitory computer-readable storage medium of claim 16, wherein the instructions, when executed, cause one or more processors of the mobile device to: Based on the link service profile, modify the content download to the mobile device via the application by at least one of the following: blocking the download, changing the download rate, or caching the downloaded content.

19. The non-transitory computer-readable storage medium of claim 16, wherein the instructions, when executed, cause one or more processors of the mobile device to: The way the application is displayed on the graphical user interface (GUI) is modified based on the link service configuration file.

20. The non-transitory computer-readable storage medium of claim 19, wherein the instructions, when executed, cause one or more processors of the mobile device to: The GUI indicates that the application's capabilities are unavailable.

Images