Techniques for routing data between satellites and ground servers

Abstract

Methods, systems, and devices are described for data routing between a satellite and a terrestrial server. A terminal of the satellite may receive a data packet associated with a latency metric from a payload of the satellite. The terminal may determine whether the latency metric is less than a threshold based on a first duration associated with a first satellite being within range of a terrestrial station of a plurality of terrestrial stations. If the terminal determines that the latency metric is less than the threshold, the terminal may queue the data packet for transmission over a first data path that includes an indirect link to a terrestrial server via a second satellite. Alternatively, if the terminal determines that the latency metric is greater than the threshold, the terminal may queue the data packet for transmission over a second data path that includes a direct link to a terrestrial server.

Description

[Background technology]

[0001] The following relates generally to communications, including techniques for routing data between satellites and terrestrial servers.

[0002] The communication devices may communicate with each other using wired connections, wireless (e.g., radio frequency (RF)) connections, or both. Wireless communication between the devices may be performed using a radio spectrum designated for the service provider, a radio technology, or both. In some embodiments, the amount of information that may be communicated over a wireless communication network is based on the amount of radio spectrum designated for the service provider and the amount of frequency reuse in the area in which the service is provided. Satellites may be used for various functions and may be in various orbits, some of which may not be continuously within range of a ground station. Thus, getting data from the satellites to the ground may present challenges. Summary of the Invention

[0003] The described technology relates to improved methods, systems, devices, and apparatus supporting techniques for data routing between a satellite and a terrestrial server. A satellite (e.g., a low earth orbit (LEO) satellite or a medium earth orbit (MEO) satellite) may include a terminal for communicating with a terrestrial station. In some cases, the terminal may be configured to communicate directly with any of a number of available terrestrial stations. However, a satellite may not be within range of a terrestrial station throughout its orbit, given its orbital path across the Earth as the Earth rotates. The terminal may receive a data packet from the satellite's payload. The data packet may include metadata indicating a latency metric associated with the data packet and a quality of service (QoS) metric associated with the data packet. The terminal may determine whether the latency metric is less than a duration associated with the satellite being within range of the terrestrial station among a number of available terrestrial stations. If the terminal determines that the latency metric is less than the duration, the terminal may queue the data packet for transmission over a first data path that includes an indirect link to a terrestrial server via a second satellite (e.g., a geostationary earth orbit (GEO) satellite). Alternatively, if the terminal determines that the latency metric is greater than the duration, the terminal may queue the data packet for transmission over a second data path that includes a direct link to a ground station (e.g., a ground server). [Brief description of the drawings]

[0004] [Figure 1] FIG. 1 illustrates an example of a satellite communications system that supports techniques for data routing between satellites and terrestrial servers according to embodiments described herein. [Diagram 2] FIG. 2 illustrates an example of a system that supports techniques for data routing between satellites and terrestrial servers in accordance with an embodiment of the present disclosure. [Diagram 3] FIG. 3 illustrates an example of a process flow supporting a technique for data routing between a satellite and a terrestrial server according to an embodiment of the disclosure. [Figure 4]FIG. 4 illustrates a block diagram supporting a technique for data routing between a satellite and a terrestrial server in accordance with an embodiment of the present disclosure. [Diagram 5] FIG. 5 illustrates a flow chart illustrating a method supporting techniques for data routing between satellites and terrestrial servers according to an embodiment of the disclosure. [Figure 6] FIG. 6 illustrates a flow chart illustrating a method supporting techniques for data routing between satellites and terrestrial servers according to an embodiment of the disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] In some embodiments, a satellite, such as a low earth orbit (LEO) satellite or a medium earth orbit (MEO) satellite, may store, collect, or relay user data. The satellite may transmit the user data to a terrestrial server according to a latency (e.g., the period of time between when the satellite receives the data and when the satellite transmits the data to a terrestrial server). In some embodiments, the satellite may transmit the data to an access node associated with the terrestrial server via a direct link. The access node may be one of one or more terrestrial stations available to the satellite. Alternatively, the satellite may transmit the data via an indirect link, such as by transmitting the data to a second satellite (e.g., a geostationary orbit (GEO) satellite), which may then transmit the data to the terrestrial server. Because a direct communication link between a satellite and a particular access node may be relatively uncongested (e.g., compared to an indirect link with a GEO satellite), transmitting data via a direct link may be less expensive (e.g., using relatively less valuable communication resources) than transmitting data via an indirect link. However, because the satellite may move relative to the access node, the satellite may experience periods during which the satellite is unable to transmit data over a direct link, which may increase the latency of transmitting that data. Therefore, techniques for determining a data path for transmitting data to a terrestrial server are desirable.

[0006] As described herein, a terminal (e.g., a router) of a satellite may determine to transmit data over a first data path or a second data path. For example, the terminal of the satellite may receive a data packet from a payload of the satellite. The data packet may include metadata indicating a latency metric associated with the data packet and a quality of service (QoS) metric associated with the data packet. The terminal may determine whether the latency metric is less than a duration associated with the satellite being within range of a ground station of one or more available ground stations. If the terminal determines that the latency metric is less than the duration, the terminal may queue the data packet for transmission over a first data path that includes an indirect link to a terrestrial server via a second satellite (e.g., a GEO satellite). Alternatively, if the terminal determines that the latency metric is greater than the duration, the terminal may queue the data packet for transmission over a second data path that includes a direct link to a terrestrial server.

[0007] Aspects of the present disclosure are initially described in the context of a satellite communications system with reference to Figure 1. Aspects of the present disclosure are further described in the context of system and process flows with reference to Figures 2 and 3. Aspects of the present disclosure are further illustrated by and described with reference to block diagrams and flow charts relating to techniques for data routing between satellites and terrestrial servers with reference to Figures 4-6.

[0008] 1 illustrates an example of a satellite communications system 100 supporting techniques for data routing between satellites and terrestrial servers according to embodiments described herein. The satellite communications system 100 may include a first network 151 of ground stations 135 configured to communicate with one or more LEO satellites 110 (e.g., or MEO satellites 110) and a second network 152 of ground stations 135 configured to communicate with one or more GEO satellites 120. In some cases, some ground stations 135 may be shared between the first network 151 and the second network 152.

[0009] LEO satellite 110 may relay communication signals to GEO satellite 120 using respective communication links 122 (e.g., LEO satellite 110-a may communicate with GEO satellite 120 via communication link 122-a, and LEO satellite 110-b may communicate with GEO satellite 120 via communication link 122-b). LEO satellite 110, GEO satellite 120, or both may be equipped with multiple antennas (e.g., one or more antenna feeds or antenna arrays). Additionally, LEO satellite 110, GEO satellite 120, or both may transmit communication signals to ground station 135, e.g., to transfer data or other digital information stored on LEO satellite 110, GEO satellite 120, or both.

[0010] The ground station 135 may include one or more access nodes 140 configured to communicate with satellites, such as the LEO satellite 110 or the GEO satellite 120, via the communication link 132. The access nodes 140 may be coupled to an access node transceiver 145 configured to process signals received from and to be transmitted through the corresponding access node(s) 140. The access node transceiver 145 may also be configured to interface with the network 125 (e.g., the Internet) via, for example, a ground server 130 (e.g., a network device, a network operations center, a satellite and gateway terminal command center, or other central processing center or device) that may provide an interface for communicating with the network 125. The ground station 135 may also include the access node 140 with multiple antennas or antenna array elements.

[0011] In some embodiments, the access node transceiver 145 may process communication signals received at the access node 140, e.g., downconvert, demodulate, and decode the communication signals. The access node transceiver 145 may also process communication signals to be transmitted from the access node 140, e.g., upconvert, encode, and modulate the communication signals.

[0012] The LEO satellite 110 may include multiple components mounted on a chassis, such as sensing components, processing components, or communication components. The chassis may include structural components as well as power systems for other components (e.g., solar arrays, batteries), on-board communications (e.g., communications buses), and station-keeping components (e.g., thrusters). The communications components may include terminals, such as routers, configured to support transmitting data to a ground station 135 using antennas and radio frequency (RF) devices on board the LEO satellite 110. The LEO satellite may be operated by a user for purposes related to payload functions (e.g., communications, sensing). For example, the LEO satellite 110 may receive, collect, and store data, such as sensor data collected by the LEO satellite 110, user data (e.g., communications data) of an entity operating the LEO satellite's payload, data received from other satellites, or other forms of data. The data may be organized into one or more data packets, each of which may contain a portion of the data. In some cases, the data packets may further include a header that may store metadata associated with the data of the data packet. In some cases, the data packets stored in the LEO satellite may have a latency associated with delivery. For example, a user of the payload of the LEO satellite 110 may enter into a service license agreement (SLA) with an operator of the satellite system to transfer data (e.g., data packets) from the satellite to a terrestrial server. The operator of the satellite system may provide a component of the LEO satellite to communicate data to a terrestrial station. The SLA may be associated with a policy for the transfer of data according to various metrics of the service, such as data volume, data latency, or data type. For example, the policy may indicate a latency (e.g., maximum latency) associated with the delivery of the data packets to be transferred to the terrestrial server 130. The terminal may manage the data packets according to the policy for transmitting the data packets to the terrestrial station 135, for example, transmitting the data packets according to a latency associated with the delivery of the data packets.

[0013] For example, if a LEO satellite is within range of ground station 135 (e.g., if ground station 135 is within coverage area 115-a of LEO satellite 110-a or coverage area 115-b of LEO satellite 110-b), the terminal may schedule a data packet for transmission to ground station 135, possibly using a direct communications link 132 (e.g., a communications link 132 that is not intercepted or forwarded by a separate entity between LEO satellite 110 and ground station 135). In some embodiments, such a data path may be referred to as a direct to earth (DTE) path, and the associated ground station 135 may be referred to as a DTE site.

[0014] In some embodiments, the coverage area 115 of an individual LEO satellite 110 may change over time. For example, as a LEO satellite 110-a moves over the Earth's surface, the corresponding coverage area 115-a may also move along with the LEO satellite 110-a. Thus, an individual LEO satellite 110 may move in and out of range of a ground station 135. For example, some LEO satellites 110 may perform polar orbits in which the LEO satellite passes over the North and South Pole of the Earth in each orbit, but may also pass over different regions of the Earth between the poles in each orbit. Thus, such a LEO satellite 110 may not be reliably within range of a ground station between the North and South Pole. In some cases, a terminal of a LEO satellite 110 may have access to data indicating the location of the LEO satellite 110, as well as the respective locations of a network of ground stations 135. Using the location data, the terminal can determine a predicted period during which the LEO satellite 110 will be within range of the ground station 135. In some embodiments, if the duration to that period is less than the latency associated with delivery of the data packet, the terminal may queue the data packet for transmission using the DTE link during that period.

[0015] Alternatively, if the duration to the period is longer than the latency associated with the delivery of the data packet, the terminal may schedule the data packet for transmission using an indirect link. For example, the terminal may schedule the data packet for transmission to the GEO satellite 120 via the communication link 122. Upon receiving the data packet, the GEO satellite 120 may retransmit the data packet to the ground station 135 of the second network 152 using the communication link 132. In some cases, such a data path may be referred to as a LEO to GEO (L2G) path. The ground station 135 may route the data packet to the terrestrial server 130, for example, via the network 125.

[0016] In some cases, the ground station 135 may be within an exclusion zone 138. As described herein, the exclusion zone 138 for a data packet may be indicated by a policy associated with the data packet. Additionally or alternatively, the exclusion zone 138 may be indicated within metadata (e.g., a header) of the data packet. The exclusion zone 138 may be sensor-specific, location-specific, etc., and may refer to an area or region (e.g., a country, an unsafe location) where transmitted data may be unsafe or undesirable. If the terminal determines that the ground station 135 is within the exclusion zone (e.g., the delay to the next ground station outside the exclusion zone exceeds a latency metric), the terminal may refrain from transmitting the data packet to the ground station 135 and may instead transmit the data packet using an alternate route, such as an indirect link.

[0017] FIG. 2 illustrates an example of a system 200 for a satellite communication system supporting techniques for data routing between a satellite and a terrestrial server according to embodiments described herein. The system 200 may include a satellite 110-c, which may be an example of a LEO satellite 110 as described with reference to FIG. 1, and the satellite 110-c may communicate with the terrestrial server 130-a using a GEO satellite 120-a, a ground station 135-a, or both. For example, the satellite 110-c may include an L2G modem 225 configured to transmit data to the GEO satellite 120-a, which may forward the data to the terrestrial server 130-a via the ground station 135-b. Additionally, the satellite 110-c may include a DTE modem 230 configured to transmit data to the ground station 135-a, which may forward the data to the terrestrial server 130-a via, for example, the network 125-a.

[0018] Satellite 110-a may include spacecraft network 205. Spacecraft network 205 may be an example of a local area network (LAN) and may support communications between components of satellite 110-c. For example, spacecraft network 205 may support communication of one or more data packets of payload 210 (e.g., user data, one or more portions of payload 210) stored in memory of satellite 110-c to terminals 215 of spacecraft network 205.

[0019] The terminal 215 may be an example of a router, such as a smart router, that may manage the data path of a data packet between the satellite 110-c and the terrestrial server 130-a according to a policy associated with the data packet. For example, the terminal 215 may determine to route the data packet to the terrestrial server 130-a via the first data path 220 or the second data path 222 based on the metadata of the data packet. In some cases, the terminal 215 may include or communicate with a policy engine 217 that may store and manage one or more policies associated with a user and data packets corresponding to the user (e.g., owned by the user). The policy engine 217 may support configuration of metadata of the data packet, such as providing a latency metric (e.g., a latency associated with a delivery as described with reference to FIG. 1), a quality of service (QoS) metric, or both, to the metadata. In some cases, the terminal 215 may include a controller coupled to a memory device to support execution of various functions, such as managing the data path, as described herein.

[0020] The first data path 220 may include an indirect link to the terrestrial server 130-a. For example, if the terminal 215 decides to transmit a data packet over the first data path 220, the terminal 215 may store the data packet in a queue 213 associated with the L2G modem 225. The terminal 215 may send an indication to the L2G modem 225 that the data packet has been queued along with a QoS associated with the data packet. In some cases, the indication may include a request for resources (e.g., communication resources, one or more time-frequency resources) from the L2G modem 225 using, for example, a QoS metric included in the metadata of the data.

[0021] The L2G modem 225 may process the request using, for example, the network processing component 235 and may use the QoS metrics to determine whether resources are available for the data packet. If the L2G modem 225 determines that resources are available for the data packet, the L2G modem 225 may schedule and transmit the data packet to the GEO satellite 120-a.

[0022] In some cases, upon receiving a request for resources and associated QoS metrics, the L2G modem 225 may determine that resources corresponding to the QoS metrics are not available. In such cases, the L2G modem 225 may reject the request (e.g., leave the data packet in a queue for one or more time periods associated with the resources used for transmission from the modem 225). In response, the terminal 215 may store the data packet for a period of time and submit a second request for resources after that period of time (e.g., or the first request may remain pending). Additionally or alternatively, the terminal 215 may update (e.g., increase) the QoS metric of the data packet according to a policy associated with the data packet and submit a second request for resources to the L2G modem 225 using the updated QoS metric.

[0023] The L2G modem 225 may transmit the data packets to the GEO satellite 120-a, for example using the RF component 240, the antenna unit 245, or both. The GEO satellite 120-a may receive the data packets and retransmit them to the ground station 135-b, which may then relay the data packets to the terrestrial server 130-a, for example, via the network 125-a or via a separate connection to the terrestrial server 130-a.

[0024] The second data path 222 may include a direct link to the terrestrial server 130-a. For example, when the terminal 215 determines to transmit a data packet over the second data path 222, the terminal 215 may store the data packet in a queue 214 associated with the DTE modem 230. The terminal 215 may send an indication to the DTE modem 230 that the data packet has been queued. In some cases, the indication may include a request for resources (e.g., communication resources, one or more time-frequency resources) from the DTE modem 230. In some cases, the indication that the data packet has been queued may include an indication of a QoS associated with the data packet.

[0025] DTE modem 230 may process the request using, for example, network processing component 250, and determine whether resources are available for the data packet. In some cases, the processing of the request may be performed according to the QoS of the data packet (e.g., the available resources may be determined according to the QoS). If DTE modem 230 determines that resources are available for the data packet, DTE modem 230 may schedule and transmit the data packet to ground station 135-a.

[0026] The DTE modem 230 may transmit the data packets to the ground station 135-a, for example using the RF component 255, the antenna unit 260, or both. The ground station 135-a may receive the data packets and retransmit them to the ground server 130-a, for example over the network 125-a.

[0027] In some cases, as described with reference to FIG. 1, the terminal 215 may determine whether the ground station 135-a is within an exclusion zone 138. As described herein, the exclusion zone 138 for the data packet may be indicated by a policy engine (e.g., according to a policy associated with the data packet). Additionally or alternatively, the exclusion zone 138 may be indicated in the metadata by the payload 210. The exclusion zone 138 may be sensor-specific, location-specific, etc., and may refer to an area or region (e.g., a country, an unsafe location) where transmitted data may be unsafe or undesirable. If the terminal 215 determines that the ground station 135-a is within the exclusion zone (e.g., the delay to the next ground station outside the exclusion zone exceeds a latency metric), the terminal 215 may remove the data packet from the queue 214 associated with the DTE modem 230 and insert the data packet into the queue 213 associated with the L2G modem 225 for transmission over the first data path 220.

[0028] In some embodiments, the terminal 215 may receive a policy for the data packet from a ground station, such as a terrestrial policy control manager, which may be an example of the terrestrial server 130 or a ground station 135. For example, the policy control manager may transmit a policy or an update to a policy associated with an owner of the data packet over the first data path or the second data path. Additionally, the policy control manager may transmit a resource schedule indicating a schedule of available communication resources associated with one or more ground stations 135, an indication of the location of each ground station, an indication of an exclusion zone, or a combination thereof, over the first data path or the second data path.

[0029] FIG. 3 illustrates an example of a process flow 300 supporting a technique for data routing between a satellite and a terrestrial server according to aspects of the disclosure. In some embodiments, the process flow 300 may be implemented by aspects of the systems 100 and 200. For example, the process flow 300 may include operations performed by aspects of a satellite, such as a LEO satellite 110 having a terminal (e.g., a router, terminal 215) coupled to an L2G modem 225 and a DTE modem 230, which may be examples of corresponding devices as described with reference to FIGS. 1 and 2. In some embodiments, the terminal may access information associated with the satellite, such as location information, velocity information, information indicating a time when the satellite is within range of a terrestrial station, or a combination thereof. In the following description of the process flow 300, operations may be performed in a different order than shown. Some operations may be excluded from the process flow 300, and other operations may be added to the process flow 300.

[0030] The process flow 300 may illustrate a process for determining a data path for transmitting a data packet 305 from a satellite payload to a terrestrial server according to a policy. For example, the policy may indicate a latency metric (e.g., a duration associated with communication of the data packet from the satellite to the terrestrial server), a QoS metric associated with the priority of the data packet, or both. In some embodiments, the satellite, or an aspect thereof, such as a terminal, a router, or a policy engine, may manage the policy and may add metadata to the data packet indicating the latency metric, the QoS metric, or both. Thus, at 310, the terminal may receive the data packet from the payload and read the metadata (e.g., a header of the data packet) to determine a latency metric associated with the data packet, a QoS metric associated with the data packet, or both.

[0031] At 315, the terminal may determine whether the latency metric is less than a threshold. The threshold may correspond to a period until the satellite is within range of a ground station (e.g., a ground station that may allow a DTE link from the satellite to a terrestrial server). Additionally or alternatively, the threshold may correspond to the greater of a period until the satellite is within range of the ground station and a period associated with scheduling and preparing data packets for transmission to the ground station. If the latency metric is less than the threshold, the terminal may queue the data packets in 320 in a queue associated with a first data path (e.g., first data path 220), such as an indirect path through a GEO satellite.

[0032] At 325, the terminal may determine whether an amount of available resources associated with the first data path (e.g., an amount of available resources of the L2G modem 225 for communicating with the GEO satellite) exceeds a threshold. For example, the terminal may determine whether the amount of available resources (e.g., the amount of resources available for the QoS metrics) is sufficient to transmit a data packet over the first data path by sending a request for resources to the L2G modem according to the QoS metrics. If the terminal determines that the amount of available resources is sufficient for the data packet, the terminal may schedule the data packet for transmission over the first data path at 330, and the L2G modem may transmit the data packet to a terrestrial server via the GEO satellite and a terrestrial station in communication with the GEO satellite.

[0033] If the terminal determines that the amount of available resources is not sufficient for the data packet, the terminal may store the data packet (e.g., in a queue associated with the L2G modem) for a duration. In some embodiments, the L2G modem may receive an updated schedule of available resources (e.g., from a GEO satellite, from a ground station, or both). Thus, if the updated resources are sufficient for the data packet (e.g., if resources are available for the QoS metrics), the L2G modem may send an indication to the terminal. In some cases, as part of storing the data packet for the duration, the terminal may update (e.g., increase) the QoS metric of the data packet at 335. For example, if the latency metric reaches a second threshold, the terminal may increase the QoS metric according to a policy associated with the data packet such that a request for resources from the L2G modem may include the updated QoS metric, and thus have a higher priority for receiving the resources.

[0034] In some cases, at 315, the terminal may determine that the latency metric exceeds a threshold. In such a case, the terminal may decide to transmit the data packet to the terrestrial server using a second data path (e.g., second data path 222), such as a direct link to the terrestrial station or a DTE link. Thus, at 340, the terminal may queue the data packet in a queue associated with the DTE modem.

[0035] In some embodiments, at 345, the terminal may determine whether an earth station associated with the second data path is within an exclusion zone. For example, the terminal may compare an identifier of the earth station to a catalog of earth stations within the exclusion zone (e.g., a catalog included in a resource schedule received from a policy control manager, as described with reference to FIG. 2). If the terminal determines that the earth station is within the exclusion zone (e.g., the delay to the next earth station exceeds a latency metric), the terminal may remove the data packet from a queue associated with the second data path and may queue the data packet in a queue associated with the first data path for transmission over the first data path.

[0036] Alternatively, if the terminal determines that the ground station is not within the exclusion zone, the terminal may schedule 350 the data packet for transmission over the second data path, and the DTE modem may transmit the data packet to the ground station. The ground station may forward the data packet to a ground server, for example, using a network (e.g., network 125).

[0037] 4 illustrates a block diagram 400 of a communication system 420 supporting techniques for data routing between a satellite and a terrestrial server according to aspects of the disclosure. The communication system 420 may be an example of aspects of a communication system as described with reference to FIGS. 1-3. For example, the communication system 420 may be an example of a terminal 215, an L2G modem 225, a DTE modem 230, or a combination thereof, as described with reference to FIG. 2. The communication system 420, or various components thereof, may be an example of a means for performing various aspects of techniques for data routing between a satellite and a terrestrial server as described herein. For example, the communication system 420 may include a receiving component 425, such as the antenna unit 245, the antenna unit 260, or both, a latency control component 430, which may be an example of the policy engine 217, a queuing component 435, which may be an example of the terminal 215, a resource acquisition component 440, which may be an example of the terminal 215, a transmitting component 445, such as the antenna unit 245, the antenna unit 260, or both, a storage component 450, which may be an example of the policy engine 217, a policy control component 455, which may be an example of the policy engine 217, or any combination thereof. Each of these components may communicate with each other directly or indirectly.

[0038] The receiving component 425 may be configured as or may support a means for receiving a data packet from a payload of a first satellite at a terminal of the first satellite of the plurality of first satellites, the data packet may include metadata indicative of a latency metric associated with the data packet and a quality of service (QoS) metric associated with the data packet. The latency control component 430 may be configured as or may support a means for determining whether the latency metric is less than a threshold, the threshold being based at least in part on a first duration associated with the first satellite being within range of a ground station of the plurality of ground stations. The queuing component 435 may be configured as or may support a means for queuing the data packet for transmission over a first data path of a plurality of data paths from the first satellite to a ground server for the data packet, based at least in part on determining that the latency metric is less than a threshold, the first data path being associated with an indirect link via one or more second satellites, the plurality of data paths including the first data path and a second data path associated with a direct link to one or more of the plurality of ground stations.

[0039] In some embodiments, the resource acquisition component 440 may be configured as or support a means for determining whether an amount of available resources associated with the indirect link exceeds a second threshold based at least in part on the queuing of the data packet, the amount of available resources being based at least in part on a quality of service (QoS) metric associated with the data packet and included in the metadata. In some embodiments, the transmission component 445 may be configured as or support a means for transmitting the data packet to the terrestrial server via the first data path based at least in part on determining that the amount of available resources exceeds the second threshold.

[0040] In some embodiments, the receiving component 425 may be configured as or may support a means for receiving a resource schedule of an amount of available resources from a ground station.

[0041] In some embodiments, the threshold value comprises a function of the first duration and a second duration associated with queuing the data packet for transmission.

[0042] In some embodiments, the resource acquisition component 440 may be configured or may support a means for determining whether an amount of available resources associated with the indirect link exceeds a second threshold, the amount of available resources based at least in part on a quality of service (QoS) metric associated with the data packet and included in the metadata. In some embodiments, the storage component 450 may be configured or may support a means for storing the data packet for a period of time based at least in part on determining that the amount does not exceed the second threshold.

[0043] In some embodiments, the resource acquisition component 440 may be configured as or support a means for updating QoS metrics based at least in part on a policy stored in the terminal and updating latency metrics based on an elapsed time since the data packet was received. In some embodiments, the resource acquisition component 440 may be configured as or support a means for determining whether a second amount of available resources associated with the indirect link exceeds a second threshold, the second amount of available resources based at least in part on the updated QoS metrics. In some embodiments, the transmission component 445 may be configured as or support a means for transmitting the data packet to the terrestrial server via the first data path based at least in part on determining that the second amount of available resources exceeds the second threshold.

[0044] In some embodiments, the receiving component 425 may be configured or may support a means for receiving a policy from a ground station.

[0045] In some embodiments, the terminal comprises a policy engine configured to manage the policies.

[0046] In some embodiments, the receiving component 425 may be configured as or support a means for receiving a data packet from a payload of a first satellite at a terminal of the first satellite of the plurality of first satellites, the data packet including metadata indicative of a latency metric associated with the data packet and a quality of service (QoS) metric associated with the data packet. In some embodiments, the latency control component 430 may be configured as or support a means for determining whether the latency metric is less than a threshold, the threshold being based at least in part on a first duration associated with the first satellite being within range of a ground station of the plurality of ground stations. In some embodiments, the queuing component 435 may be configured as or support a means for queuing the data packet for transmission over a second data path of a plurality of data paths from the first satellite to a ground server for the data packet, based at least in part on determining that the latency metric is greater than or equal to a threshold, the second data path being associated with a direct link to the ground station, the plurality of data paths including a second data path and a first data path associated with an indirect link via one or more second satellites.

[0047] In some embodiments, the transmission component 445 may be configured as or support a means for transmitting data packets to a ground server via a second data path based at least in part on the queuing.

[0048] In some embodiments, the policy control component 455 may be configured as or support a means for determining whether the ground station is within an exclusion zone. In some embodiments, the queuing component 435 may be configured as or support a means for queuing data packets for transmission over the first data path based at least in part on determining that the ground station is within an exclusion zone. In some embodiments, the transmission component 445 may be configured as or support a means for transmitting data packets to a ground server over the first data path.

[0049] FIG. 5 illustrates a flow chart illustrating a method 500 supporting techniques for data routing between a satellite and a terrestrial server, according to an embodiment of the present disclosure. The operations of method 500 may be implemented by a communications system or components thereof, as described herein. For example, the operations of method 500 may be performed by a communications system, as described with reference to FIGS. 1-4. In some embodiments, the communications system may execute a set of instructions to control functional elements of the communications system to perform the described functions. Additionally or alternatively, the communications system may perform aspects of the described functions using dedicated hardware.

[0050] At 505, the method may include receiving, at a terminal of a first satellite of the plurality of first satellites, a data packet from a payload of the first satellite, the data packet including metadata indicative of a latency metric associated with the data packet and a quality of service (QoS) metric associated with the data packet. The operations of 505 may be performed according to embodiments as disclosed herein. In some embodiments, aspects of the operations of 505 may be performed by a receiving component 425 as described with reference to FIG. 4.

[0051] At 510, the method may include determining whether the latency metric is less than a threshold, the threshold being based at least in part on a first duration associated with the first satellite being within range of a ground station of the plurality of ground stations. The operations of 510 may be performed according to embodiments as disclosed herein. In some embodiments, aspects of the operations of 510 may be performed by a latency control component 430 as described with reference to FIG.

[0052] At 515, the method may include queuing the data packet for transmission over a first data path of a plurality of data paths from the first satellite to a ground server for the data packet based at least in part on determining that the latency metric is less than a threshold, the first data path being associated with an indirect link via one or more second satellites, the plurality of data paths including the first data path and a second data path associated with a direct link to one or more of the plurality of ground stations. The operations of 515 may be performed according to embodiments as disclosed herein. In some embodiments, aspects of the operations of 515 may be performed by a queuing component 435 as described with reference to FIG. 4.

[0053] FIG. 6 illustrates a flow chart illustrating a method 600 supporting techniques for data routing between a satellite and a terrestrial server, according to an aspect of the disclosure. The operations of method 600 may be implemented by a communications system or components thereof, as described herein. For example, the operations of method 600 may be performed by a communications system, as described with reference to FIGS. 1-4. In some embodiments, the communications system may execute a set of instructions to control functional elements of the communications system to perform the described functions. Additionally or alternatively, the communications system may perform aspects of the described functions using dedicated hardware.

[0054] At 605, the method may include receiving, at a terminal of a first satellite of the plurality of first satellites, a data packet from a payload of the first satellite, the data packet including metadata indicating a latency metric associated with the data packet and a quality of service (QoS) metric associated with the data packet. The operations of 605 may be performed according to embodiments as disclosed herein. In some embodiments, aspects of the operations of 605 may be performed by a receiving component 425 as described with reference to FIG. 4.

[0055] At 610, the method may include determining whether the latency metric is less than a threshold, the threshold being based at least in part on a first duration associated with the first satellite being within range of a ground station of the plurality of ground stations. The operations of 610 may be performed according to embodiments as disclosed herein. In some embodiments, aspects of the operations of 610 may be performed by a latency control component 430 as described with reference to FIG.

[0056] At 615, the method may include queuing the data packet for transmission over a second data path of a plurality of data paths from the first satellite to a ground server for the data packet based at least in part on determining that the latency metric is equal to or greater than a threshold, the second data path being associated with a direct link to the ground station, the plurality of data paths including the second data path and the first data path associated with an indirect link via one or more second satellites. The operations of 615 may be performed according to embodiments as disclosed herein. In some embodiments, aspects of the operations of 615 may be performed by a queuing component 435 as described with reference to FIG. 4.

[0057] It should be noted that these methods describe example implementations, and that the acts and steps may be rearranged or otherwise modified such that other implementations are possible. In some embodiments, aspects from two or more of the methods may be combined. For example, aspects of each method may include steps or aspects of other methods, or other steps or techniques described herein.

[0058] The information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the specification may be represented as voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or photons, or any combination thereof.

[0059] The various example blocks and modules described in connection with the disclosure herein may be implemented or performed using a general purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration).

[0060] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, depending on the nature of the software, the functions described herein may be implemented using software executed by a processor, hardware, firmware, hardwiring, or any combination thereof. Features implementing the functions may also be physically located in various locations, including being distributed such that some of the functions are implemented in different physical locations.

[0061] Computer-readable media may include both non-transitory computer storage media and communication media, including any medium that facilitates transfer of a computer program from one place to another. Non-transitory storage media may be any available medium accessible by a general purpose or special purpose computer. By way of example, and not limitation, non-transitory computer-readable media may include RAM, ROM, Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory, Compact Disk Read-Only Memory (CDROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general purpose or special purpose computer, or a general purpose or special purpose processor. Any connection is also properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio and microwave are included within the definition of media. Disk and disc, as used herein, include CDs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while discs reproduce data optically with a laser. Combinations of the above are also included within the scope of computer readable media.

[0062] As used herein, including the claims, "or" used in a list of items (e.g., a list of items prefaced by a phrase such as "at least one" or "one or more") indicates an inclusive list, such as, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase "based on" should not be construed as a reference to a closed set of conditions. For example, an example step described as "based on condition A" may be based on both condition A and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" is to be interpreted the same as the phrase "based at least in part on."

[0063] In the accompanying drawings, similar components or features may have the same reference label. Additionally, various components of the same type may be distinguished by following the reference label with a dash and a second label that distinguishes between the similar components. If only a first reference label is used in the description, the description is applicable to any of the similar components with the same first reference label, regardless of the second reference label or any other reference labels that follow.

[0064] The description set forth herein in conjunction with the accompanying drawings describes exemplary configurations and does not represent every embodiment that may be implemented or fall within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration" and not "preferred" or "advantageous over other examples." The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, these technologies may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described embodiments.

[0065] The description herein is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the embodiments and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. 1. A method comprising: receiving, at a terminal (215) of a first satellite (110-c) of a plurality of first satellites (110), a data packet (305) from a payload (210) of the first satellite (110-c), the data packet (305) including metadata indicative of a latency metric associated with the data packet (305) and a quality of service (QoS) metric associated with the data packet (305), the latency metric including a duration associated with communicating the data packet (305) from the first satellite (110-c) to a terrestrial server (130-a) for the data packet (305), the terrestrial server (130-a) being coupled to a plurality of ground stations (135); determining whether the latency metric is less than a duration threshold, the duration threshold being based at least in part on a first time period until the first satellite (110-c) comes within range of a ground station (135) of the plurality of ground stations (135); queuing the data packet (305) for transmission over a first data path (220) of a plurality of data paths from the first satellite (110-c) to the terrestrial server (130-a) for the data packet (305), the first data path (220) being associated with an indirect link (122) via one or more second satellites (120), the plurality of data paths including the first data path (220) and a second data path (222) associated with a direct link (132) to the terrestrial station (135); and queuing the data packet (305) for transmission over the second data path (222) in response to determining that the latency metric is greater than or equal to the duration threshold; transmitting the data packet (305) over the first data path or the second data path.

2. determining, based at least in part on queuing the data packet (305), whether an amount of available resources associated with the indirect link (122) exceeds a second threshold, the amount of available resources being based at least in part on the QoS metric associated with the data packet (305) and included in the metadata; 2. The method of claim 1, further comprising: transmitting the data packet (305) to the terrestrial server (130-a) via the first data path (220) based at least in part on determining that the amount of available resources exceeds the second threshold.

3. The method of claim 2 , further comprising receiving a resource schedule of the amount of available resources from a second ground station (135) of a plurality of ground stations (135).

4. 4. The method of claim 1, wherein the duration threshold comprises a function of the first duration and a second duration associated with queuing the data packet for transmission.

5. determining whether an amount of available resources associated with the indirect link (122) exceeds a second threshold, the amount of available resources being based at least in part on the QoS metrics associated with the data packet (305) and included in the metadata; 4. The method of claim 1, further comprising: storing the data packet (305) for a period of time based at least in part on determining that the amount does not exceed the second threshold.

6. updating the QoS metric based at least in part on a policy stored in the terminal (215), and updating the latency metric based on an elapsed time since the data packet (305) was received; determining whether a second amount of available resources associated with the indirect link (122) exceeds the second threshold, the second amount of available resources being based at least in part on the updated QoS metrics; 6. The method of claim 5, further comprising: transmitting the data packet (305) to the ground server (130-a) via the first data path (220) based at least in part on determining that the second amount of available resources exceeds the second threshold.

7. The method of claim 6, further comprising receiving the policy from a ground station (130).

8. The method of claim 6, wherein the terminal (215) comprises a policy engine (217) configured to manage the policy.

9. 2. The method of claim 1, further comprising transmitting the data packets (305) to the terrestrial server (130-a) via the second data path (222) based at least in part on the queuing.

10. determining whether the ground station (135) is within an exclusion zone (138); queuing the data packet (305) for transmission over the first data path (220) based at least in part on determining that the ground station (135) is within the exclusion zone (138); and The method of any one of claims 1 to 3, further comprising transmitting the data packet (305) to the ground server (130-a) via the first data path (220).

11. 1. An apparatus configured to perform the following operations: receiving, at a terminal (215) of a first satellite (110-c) of a plurality of first satellites (110), a data packet (305) from a payload (210) of the first satellite (110-c), the data packet (305) including metadata indicative of a latency metric associated with the data packet (305) and a quality of service (QoS) metric associated with the data packet (305), the latency metric including a duration associated with communicating the data packet (305) from the first satellite (110-c) to a terrestrial server (130-a) for the data packet (305), the terrestrial server (130-a) being coupled to a plurality of ground stations (135); determining whether the latency metric is less than a duration threshold, the duration threshold being based at least in part on a first time period until the first satellite (110-c) comes within range of a ground station (135) of the plurality of ground stations (135); queuing the data packet (305) for transmission over a first data path (220) of a plurality of data paths from the first satellite (110-c) to the terrestrial server (130-a) for the data packet (305), the first data path (220) being associated with an indirect link (122) via one or more second satellites (120), the plurality of data paths including the first data path (220) and a second data path (222) associated with a direct link (132) to the terrestrial station (135); and queuing the data packet (305) for transmission over the second data path (222) in response to determining that the latency metric is greater than or equal to the duration threshold; transmitting the data packet (305) over the first data path or the second data path.

12. determining, based at least in part on queuing the data packet (305), whether an amount of available resources associated with the indirect link (122), based at least in part on the QoS metric associated with the data packet (305) and included in the metadata, exceeds a second threshold; 12. The apparatus of claim 11, further configured to transmit the data packet (305) to the terrestrial server (130-a) via the first data path (220) based at least in part on determining that the amount of available resources exceeds the second threshold.

13. The apparatus of claim 12 , further configured to receive a resource schedule of the amount of available resources from a second ground station (135) of the plurality of ground stations.

14. 14. The apparatus of claim 11, wherein the duration threshold comprises a function of a first duration and a second duration associated with queuing the data packet (305) for transmission.

15. determining whether an amount of available resources associated with the indirect link (122), based at least in part on the QoS metric associated with the data packet (305) and included in the metadata, exceeds a second threshold; 14. The apparatus of claim 11, further configured to store the data packet (305) for a period of time based at least in part on determining that the amount does not exceed the second threshold.

16. updating the QoS metric based at least in part on a policy stored in the terminal (215); and updating the latency metric based on an elapsed time since the data packet (305) was received; determining whether a second amount of available resources associated with the indirect link (122), based at least in part on the updated QoS metric, exceeds the second threshold; 16. The apparatus of claim 15, further configured to transmit the data packet (305) to the ground server (130-a) via the first data path (220) based at least in part on determining that the second amount of available resources exceeds the second threshold.

17. The apparatus of claim 16, further configured to receive the policy from a ground station (130).

18. 17. The apparatus of claim 16, wherein the terminal (215) comprises a policy engine (217) configured to manage the policy.

Images