Patent Description:
Terrestrial communication is utilized as a wireless communication technology, e.g., for communication of IoT (Internet of Things) devices to a remote server, etc. IoT devices such as sensors, actuators, smart devices, etc., may be deployed in various geographical areas. The IoT devices typically send data to a remote computer, e.g., an IoT server, and/or receive data from the remote computer. A congestion of a wireless network such as a terrestrial communication network and/or inadequate coverage of a location, e.g., unserved or underserved remote areas, may impact an operation of IoT devices.

Published European patent application <CIT> discloses a satellite route installed to augment the capacity of a terrestrial route. A specialized forwarding unit is introduced at both ends of these parallel satellite and terrestrial routes. The forwarding unit identifies what type of traffic needs a higher performance forward, and forwards the traffic accordingly. For example, latency-sensitive traffic can be forwarded over the terrestrial route and the latency insensitive traffic can be forwarded over the satellite route.

Published US patent application discloses an approach for cost effective backhaul services in terrestrial mobile communications systems. Data traffic over a terrestrial communications path between a cell site and a core network of a cellular communications network is monitored. The presence of a threshold level of congestion over the terrestrial communications path is determined. Appropriate portions of the data traffic for transfer to a satellite communications link between the cell site and the core network of the cellular communications network are determined. The determined portions of the data traffic are transferred from the terrestrial communications path to the satellite communications link. Once the threshold level of congestion over the terrestrial communications path has subsided, the determined portions of the data traffic are transferred from the satellite communications link back to the terrestrial communications path.

Published European patent application <CIT> discloses a load balancing technique for optimally routing data packets to a hybrid terminal over an asymmetric hybrid network link, which utilizes a bi-directional terrestrial channel and a satellite channel. For each data packet received from an Internet server, a load-balancing algorithm is employed to determine whether to route the packet via the bi-directional terrestrial channel or the satellite channel. The load-balancing algorithm is designed so relatively small data packets are transmitted over the bi-directional terrestrial channel, while larger data packets are transmitted over the satellite channel. All data packets lost during terrestrial transmission are re-transmitted over the satellite channel. Additional value-added services are added to redirect all Internet traffic terrestrially when the hybrid terminal. experiences rain fade or other condition, which disrupts the satellite channel.

Published US patent application <CIT> discloses a requesting terminal including an interface that allows a user to select whether data downloaded from a network (such as the Internet) is transmitted to the requesting terminal via a high-speed link, such as a satellite link, or a lower speed link, such as a terrestrial link. The terrestrial link (which may comprise a conventional dial-up Internet connection) is a two-way link, wherein the requesting terminal transmits data requests to the network via the terrestrial link. The data requests generated by the requesting terminal are modified to designate whether the requested data should be downloaded from the network via the terrestrial link or the satellite link. The terrestrial link may also be automatically selected for certain applications.

The invention is defined by the independent claims to which reference is now made. Advantageous features are set out in the dependent claims.

Disclosed herein is a system comprising a terminal. The terminal includes a terrestrial communication interface, a satellite communication interface, and a computer. The terrestrial and satellite communication interfaces are configured to communicate traffic data. The computer is communicatively linked to the terrestrial and satellite communication interfaces, and the executes instructions comprising, to determine that the traffic data, communicated via the terrestrial communication interface, exceeds a threshold, and based on the determination, route at least a portion of traffic data via the satellite communication interface in accordance with a predetermined traffic data load-balancing scheme.

The computer may be further programmed to determine a terrestrial link quantifier and a satellite link quantifier, and select at least one of the terrestrial communication interface and the satellite communication interface further based on the terrestrial link quantifier and the satellite link quantifier.

The computer may be further programmed to determine a first score of the traffic data based on at least one of a data throughput, a data type quantifier, and a terrestrial link quantifier, and to route at least the portion of traffic data via the satellite communication interface upon determining that the first score of the traffic data exceeds the threshold.

The computer may be further programmed to determine the data type quantifier based at least on one of the data throughput, a data volume, and a data priority.

The computer may be further programmed to determine the data priority based at least in part on a latency threshold of the traffic data.

The computer may be further programmed to receive, via a local communication network, a plurality of data packets from a plurality of IoT devices, generate an aggregated data packet including the received plurality of data packets, and transmit the aggregated data packet via the satellite communication interface to the remote computer.

The computer may be further programmed to determine a first score of the plurality of data packets for communicating via the terrestrial communication interface, to determine a second score of the aggregated data packet for communicating via the satellite communication interface, and to transmit the aggregated data packet via the satellite communication interface upon determining that first score exceeds the second score.

The computer may be further programmed to communicate with one or more loT devices, via an IoT interface, wherein the traffic data includes data received from or sent to the one or more loT devices.

The system includes a gateway computer, programmed to receive data from remote computer, and to multicast the received remote computer data to a plurality of terminals, wherein the plurality of terminals communicates with IoT devices via one or more local communication network.

The gateway computer is programmed to distribute an encryption key, in a unicast mode, to the plurality of second computers, to encrypt the received remote computer data with the key, and to multicast the encrypted remote computer data to the plurality of terminals.

The system may further include an IoT device comprising a second computer, programmed to receive the distributed key and the encrypted multicast data, to decrypt the multicast data based on the distributed key, and to actuate an actuator based on the decrypted data.

The gateway computer may be further programmed to receive, via a satellite uplink, a reception quality status including a link condition, and to adjust, based on the received quality status, at least one of multicast parameters including a data throughput, a transmission power, and a transmission spectral efficiency.

The gateway computer may be further programmed to divide, based on the received quality status, the plurality of terminals into a first group with a first set of multicast parameters and a second group with a second set of multicast parameters, to multicast the remote computer data based on the first set of multicast parameters via a first downlink, and to multicast the remote computer data based on the second set of multicast parameters via a second downlink.

Further disclosed herein is a system, comprising a gateway computer, programmed to receive data from a remote computer, to multicast the received data to a plurality of terminals, communicatively connected to IoT devices via one or more local communication networks, to receive, via a satellite uplink, a reception quality status from the plurality of terminals, wherein the reception quality status includes a link condition, and to adjust, based on the received quality status, at least one of multicast parameters including a data throughput, a transmission power, and a transmission spectral efficiency.

Further disclosed herein is a method, comprising determining that traffic data of a terminal, communicated via a terrestrial communication interface of the terminal, exceeds a threshold, and based on the determination, routing at least a portion of traffic data via a satellite communication interface of the terminal in accordance with a predetermined traffic data load-balancing scheme, wherein the terrestrial and satellite communication interfaces are configured to communicate traffic data.

The method may further include determining a terrestrial link quantifier and a satellite link quantifier, and selecting at least one of the terrestrial communication interface and the satellite communication interface further based on the terrestrial link quantifier and the satellite link quantifier.

The method may further include determining a score of the traffic data based on at least one of a data throughput, a data type quantifier, and a terrestrial link quantifier, and routing at least the portion of traffic data via the satellite communication interface upon determining that the score of the traffic data exceeds the threshold.

The method may further include determining the data type quantifier based at least on one of the data throughput, a data volume, and a data priority.

The method may further include determining the data priority based at least in part on a latency threshold of the traffic data.

Operation of distributed systems such as loT devices communicating with remote computers rely on wired and/or wireless communication networks which provide data communication between various parts of the system, e.g., IoT devices and IoT servers. However, a wireless communication network, e.g., a terrestrial wireless communication network, may fail to provide an efficient, reliable, and/or cost-effective path for communicating traffic data in a distributed system. This disclosure pertains to systems and methods to identify such conditions and improve wireless data communication in a distributed system.

Such a system includes a satellite terminal system having a terrestrial communication interface, a satellite communication interface, and a computer. The terrestrial and satellite communication interfaces are configured to communicate traffic data (e.g., data exchanged between the loT devices and IoT servers). The satellite terminal system further includes a computer communicatively linked to the terrestrial and satellite communication interfaces. The computer is programmed to determine that the traffic data, communicated via the terrestrial communication interface, exceeds a threshold, and based on the determination, route at least a portion of traffic data via the satellite communication interface in accordance with a predetermined traffic data load-balancing scheme. Non-limiting examples of such a system include a satellite computer that is programmed to receive, via a satellite uplink, terminal data from a satellite terminal on the ground, and multicast, via a downlink, the received terminal data, to a plurality of IoT devices.

<FIG> illustrates a block diagram of an example distributed system <NUM> including satellite terminal(s) 105A, IoT devices <NUM>, and remote computer(s) <NUM>, communicating via a combination of terrestrial communication link(s) <NUM>, satellite communication links <NUM>, local communication network(s) <NUM>, a mobile communication network such as <NUM> Core mobile backbone <NUM>, and/or an IP (Internet Protocol) network <NUM>. In the illustration, only one satellite terminal 105A is shown for purposes of illustration; however, it should be appreciated that any suitable quantity of satellite terminals 105A may be used instead. In another example embodiment, one or more loT devices <NUM> may be included in the terminal 105A. In other words, the terminal 105A may additionally provide IoT device <NUM> operation.

Distributed network <NUM> is a network of computers located in a geographical area, e.g., a building, a neighborhood, a city, a country, etc., that exchange data via a combination of wired and/or wireless communication networks. The distributed network <NUM> may include a variety of different types of communication networks such as terrestrial, satellite, local communication networks, etc., as discussed below. Internet of Things (IoT) is an example of a distributed network <NUM> including devices <NUM> such as smart devices, sensors, actuators, vehicles, etc. and remote computers <NUM> (sometimes referred to as loT servers) that are connected wired and/or wirelessly to exchange data. In the present context, a remote computer <NUM> may be programmed to communicate with a plurality, e.g., thousands, of IoT devices <NUM>, e.g., to transmit actuation instructions to an actuator IoT device <NUM>, receive data from a sensor device <NUM>, and/or update programming of an IoT device <NUM> such as a thermostat, etc. In the present context, a remote computer <NUM> may include multiple remote computers <NUM>. In other words, not all programming of computer <NUM> discussed herein is necessarily implemented in one remote computer <NUM>.

A communication network may be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks (e.g., using one or more of cellular, Bluetooth, IEEE <NUM>, etc.), local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services.

A terrestrial communication system, e.g., LTE (Long-Term Evolution), <NUM>, , etc. may include a mobile network backbone <NUM> and a plurality of base stations <NUM>. The base stations <NUM> may be connected to the backbone <NUM> via a wired and/or wireless network. The base stations <NUM> provide a terrestrial communication link <NUM>, e.g., <NUM>, LTE, etc., to the terminal 105A. The backbone <NUM> of the terrestrial communication system may be connected to an IP network <NUM>, e.g., to provide access to the remote computer <NUM> via internet. A terrestrial communication link <NUM> is established when a wireless communication, e.g., via LTE protocol, is initiated between terminal 105A and a base station <NUM>.

An IP (Internet Protocol) network <NUM> has a task of delivering data packets from a source host to a destination host solely based on an IP addresses in the packet headers. For this purpose, IP defines packet structures that encapsulate the data to be delivered. It also defines addressing methods that are used to label the datagram with source and destination information.

IoT devices <NUM> may be implemented by chips, circuits, electromechanical components, etc. IoT devices <NUM> typically include a communication interface, e.g., WiFi, Bluetooth, LAN (Local Area Network), etc., to communicate, e.g., via the terminal 105A, links <NUM>, <NUM>, etc., with a remote computer. An IoT device <NUM> may include a sensor such as temperature, pressure, etc. sensor and an IoT device <NUM> processor may be programmed to receive data from the sensor and send the received data via the IoT <NUM> interface to a remote computer. As another example, an IoT device <NUM> may include an actuator, e.g., an alarm, a relay, a hydraulic component, etc. and the IoT device <NUM> processor may be programmed to receive data from a remote computer and actuate the IoT device <NUM> actuator based on the received data. As another example, an IoT device <NUM> may be a thermostat, a programmable control unit, etc. The IoT devices <NUM> may be connected to the terminal(s) 105A via a local communication network <NUM>. The local communication network <NUM> may be an IP-based network such as an IEEE <NUM>. <NUM>, low power Wi-Fi, 6LoWPAN (IP version <NUM> over Low-Power Wireless Personal Area Networks), etc. Additionally, or alternatively, a local communication network <NUM> may be a non-IP based network such as NFC (Near-Field Communication), LoRa™ (Long Range), BLE (Bluetooth Low Energy), Zigbee, etc..

The system <NUM> may include satellite(s) <NUM> that provide wireless communication via the satellite links <NUM> to one or more terminals 105A which are within a coverage area <NUM> of the satellite <NUM>. In the present context, a satellite link <NUM> is a wireless communication between a dish <NUM> antenna and a satellite <NUM> antenna. A satellite link <NUM> may include an uplink, including communication from terminal 105A to a satellite <NUM>, a gateway <NUM>, etc. and/or a downlink, which includes communication from the satellite <NUM> to the terminal 105A, gateway <NUM>, etc..

Satellite <NUM> may include a computer <NUM> having a processor and a memory storing instructions to operate the satellite <NUM>, e.g., including providing configuring links <NUM> (uplink and/or downlink), receiving and/or transmitting data, etc. In another example, the satellite <NUM> may include a bent-pipe implementation that forwards the received information without any data processing. In the present context, a coverage area <NUM> of a satellite <NUM> is a geographical area on the surface of Earth, in which terminal 105A, gateway <NUM>, etc., may communicate with the satellite <NUM>. In one example, a coverage area <NUM> may be an area, e.g., a city, etc., covered with a spot beam. In yet another example, a coverage area <NUM> may be an area covered by a gateway beam, i.e., available for communication with a gateway <NUM> on Earth. Other parameters such as weather conditions, objects such as buildings, trees, etc., may affect a coverage area, e.g., reduce the coverage area <NUM>. A shape, dimensions, etc., of a coverage area <NUM> may depend on multiple parameters such as a distance of the satellite <NUM> from the Earth, a width of an electromagnetic beam of the satellite, etc. For example, a wide beam from satellite <NUM> may result in coverage area <NUM> being a large area, e.g., a country, whereas a narrow beam from satellite <NUM> may result in coverage area <NUM> being smaller-e.g., such as a metropolitan area.

In the present context, terminal 105A is a computer-based communication device that provides an interface between the IoT devices <NUM> (or the like) and the remote computers <NUM> via the satellite link(s) <NUM> and/or the terrestrial link(s) <NUM>. In one non-limiting example, the terminal 105A may be a very small aperture terminal (VSAT). Terminal 105A is implemented via circuits, chips, antennas, or other electronic components that can communicate with satellites <NUM> and terrestrial base stations <NUM> which are within communication range of the terminal 105A. In some instances, the terminals 105A are stationary relative to a location on Earth. In other instances, the terminal 105A is mobile, meaning that the terminal 105A moved relative to a location on the Earth. For instance, the terminal 105A may be configured to receive communications from satellite <NUM> or terrestrial base station <NUM> and transmit such communications via the local communication network <NUM>, e.g., Wi-Fi, Zigbee, etc., to the IoT devices <NUM>. Additionally, or alternatively, the terminal 105A may receive communication, e.g., sensor data, from IoT device(s) <NUM> and transmit such communication to the remote computer <NUM>.

With continued reference to <FIG>, the terminal 105A includes a computer <NUM> including a processor <NUM> and a memory <NUM>, a satellite communication interface <NUM>, terrestrial communication interface <NUM>, and a local communication interface <NUM>. The processor may be implemented via circuits, chips, or other electronic component and may include one or more microcontrollers, one or more field programmable gate arrays (FPGAs), one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more customer specific integrated circuits, etc. The processors in computers <NUM> (or other devices <NUM>, gateways <NUM>, etc.) may be programmed to execute instructions stored in the memory <NUM>, as discussed herein. The memory <NUM> includes one or more forms of computer-readable media, and stores instructions executable by the processor <NUM> for performing various operations, including as disclosed herein.

The satellite communication interface <NUM> includes physical layer components such as transceiver, modulator, demodulator, etc. to facilitate communication with satellites <NUM>. Terminal 105A may include or be communicatively connected to one or more dish(s) <NUM> and antenna(s), which allow terminal 105A to communicate with one or more satellites <NUM> at a time.

The antenna may include a low-noise block downconverter (LNB) mounted on a dish <NUM>, which may collect radio waves from the dish <NUM> and convert the collected radio waves to a signal which is sent through wired connection, e.g., a cable, to the terminal 105A. The antenna may be a combination of low-noise amplifier, frequency mixer, local oscillator and intermediate frequency (IF) amplifier. The antenna serves as a radio frequency (RF) front end of a terminal 105A, receiving a microwave signal from a satellite <NUM> collected by the dish <NUM>, amplifying the received signal, and converting the block of frequencies to a lower block of intermediate frequencies (IF). This conversion of RF to a lower block of IF, allows the signal to be carried, e.g., via a wired connection, to terminal 105A. An antenna typically includes a sender antenna configured to send radio waves to a satellite <NUM>, and/or a receiver antenna configured to receive radio waves from satellite <NUM>.

The terrestrial communication interface <NUM> facilitates communication of the terminal 105A with base station <NUM>. The terrestrial communication interface <NUM> is implemented via circuits, chips, or other electronic component such as a modulator, a demodulator, antenna, etc., configured to communicate via a specified frequency and communication protocol such as LTE, <NUM>, etc..

The local communication interface <NUM> facilitates communication of the terminal 105A via the local communication network <NUM>, e.g., Wi-Fi. The local communication interface <NUM> may be implemented via chips, modulators, demodulators, antenna, etc..

As discussed above, the terminal 105A includes satellite and terrestrial communication interfaces <NUM>, <NUM> and can communicate traffic data T via the satellite and/or terrestrial communication interface <NUM>, <NUM> (e.g., split the traffic data T between the satellite and/or terrestrial communication interfaces <NUM>, <NUM>). In this context, the computer <NUM> may coordinate the communication of the traffic data T via the satellite and/or terrestrial communication interfaces <NUM>, <NUM>. In the present context, a second computer <NUM>, e.g., included in the mobile backbone <NUM>, may be programmed to coordinate the communication of the traffic data T with the block <NUM> of terminal 105A. Thus, when traffic data T sent from the terminal 105A is split between the terrestrial and satellite communication interface <NUM>, <NUM>, the computer <NUM> of the terminal 105A sends information to the second computer in the backbone <NUM> describing how the split information can be merged together, e.g., providing a list of instructions for how the data can be merged together. Thus, the second computer in the backbone can, upon receiving the portions of the traffic data T via the satellite and terrestrial communication links <NUM>, <NUM>, merge the received data together based on instructions received from the computer <NUM>.

<FIG> shows an exemplary software architecture of terminal 105A. The exemplary blocks PHY <NUM> (or physical layer), RLC/MAC <NUM> (or Radio Link Control/Medium Access Control), and PDCP/RRC <NUM> (or Packet Data Convergence Protocol/Radio Resource Control), which are shown as redundant blocks, represent OSI (Open System Interconnection) layers for each of the satellite and terrestrial communication. PHY <NUM> represent the software programming to operate the satellite and terrestrial communication interfaces <NUM>, <NUM>. Blocks IP <NUM>, IoT Transport <NUM>, and IoT Application <NUM> represent programming of the terminals 105A with respect to communication with IoT devices <NUM> via the local communication interface <NUM>.

The computer <NUM> implements example blocks of <FIG> by executing programming stored on the memory of the computer <NUM> and actuating components of the terminal 105A, such as the communication interfaces <NUM>, <NUM>, <NUM>. Thus, computer <NUM> can be programmed to communicate traffic data T between the IoT devices <NUM> and the remote computer(s) <NUM>. In the present context, "traffic data T" includes any data including sensor data, actuation command, software update, etc., exchanged between devices <NUM> and the remote computer(s) <NUM>, e.g., sensor data sent from IoT devices <NUM> to the remote computer <NUM>, actuation command or software update sent from the remote computer <NUM> to IoT devices <NUM>. In the present context, t (T) returns a throughput of the traffic data T, e.g., <NUM> Megabit/second (Mb/s). In the present context, the operator t() returns a throughput of data being communicated through terminal 105A, via satellite link <NUM>, and/or via terrestrial link <NUM>.

Session Management and Mobility Management (SM/MM block <NUM>) serves the underlying layers of the stack, i.e., taking advantage of the fact that protocols themselves are oblivious to whether the terminal 105A is communicating over a satellite link <NUM> or terrestrial link <NUM>. In other words, the enhancements related to satellite link <NUM> and terrestrial link <NUM> are in the lower layers such as the physical layer PHY <NUM> and RLC/MAC <NUM>, and/or PDCP/RRC <NUM>. Traffic data T may be transmitted via the satellite link <NUM> based on a non-IP protocol. <FIG> illustrates an example diagram for facilitating communication between a non-IP-based satellite link <NUM> and an IP-based network <NUM>. In an example non-IP based communication, the terminal 105A computer <NUM> may be programmed to send traffic data T with an identifier (e.g., <NUM>-bit data with an extension bit) of the terminal 105A and an IoT service provider identifier (e.g., <NUM> bits data with an extension bit). Thus, the data may lack any TCP (Transmission Control Protocol)/IP header. In the present context, a service provider identifier is used to identify the remote computer, e.g., an IP address of the IoT server (i.e., the remote computer <NUM>).

Gateway computer <NUM> (also shown in <FIG>) may include a computer programmed to receive the traffic data T including the terminal 105A identifier and the service provider identifier, to convert the received traffic data T to IP-based data, and to communicate the generated IP-based data via IP network <NUM> and/or mobile backbone <NUM> to the remote computer <NUM>. The gateway <NUM> computer may communicate with the satellite <NUM> via dish <NUM> and satellite link <NUM>, as shown in <FIG>.

In one example, the gateway <NUM> computer may store, e.g., in a computer memory, a table that includes a mapping of each of the service provider identifiers and corresponding IP addresses. The gateway <NUM> computer may be programmed to send a TCP/IP or UDP/IP data packet to remote computer <NUM> by determining the IP address of the remote computer <NUM> based on the stored table and the receive service provider identifier. The generated IP-based message may further include the terminal 105A identifier. The remote computer <NUM> may be programmed to transmit data for the terminal 105A including the received terminal 105A identifier and an IP address of the gateway <NUM>. Similarly, the gateway <NUM> computer may be programmed to generate data for sending via the satellite link <NUM> to the respective terminal 105A based on the received terminal 105A identifier.

Computer <NUM> of terminal 105A can be programmed to determine that the traffic data T, communicated via the terrestrial communication interface <NUM>, exceeds a threshold, and based on the determination, route at least a portion of traffic data T via the satellite communication interface <NUM> in accordance with a predetermined traffic data load-balancing scheme. In the present context, as discussed below, a threshold is (i) a number with a unit, e.g., a data throughput threshold DT of <NUM> Megabit/second (Mb/s), or (ii) a number without a unit, e.g., a score threshold ST, a ratio, etc..

In one example, a load-balancing scheme includes a set of rules with an objective of balancing traffic load (e.g., data transmission rate) between the terrestrial and satellite communication links <NUM>, <NUM>. In the present context, a traffic load includes (i) data transmitted by the terminal 105A to the remote computer(s) <NUM>, e.g., data received from one or more IoT devices <NUM> via the local communication network <NUM>, and/or (ii) received from the remote computer(s) <NUM>, e.g., to be transmitted to the IoT devices <NUM> via the location communication network <NUM>. Herein, various non-limiting examples of load-balancing schemes are disclosed, according to which a terminal 105A computer <NUM> can be programmed to operate. Table <NUM> shows an example set of rules that can be used to balance the traffic load in the system <NUM>. For example, the terminal 105A computer <NUM> may be programmed to operate based on one or more of the rules of Table <NUM>.

<FIG> shows a flowchart of a non-limiting example process <NUM> for balancing traffic data T between terrestrial and satellite communication networks based on rules <NUM> and/or <NUM> of Table <NUM>. The computer <NUM> may be programmed to execute blocks of the exemplary process <NUM>.

The process <NUM> begins in a block <NUM>, in which the computer <NUM> determines a data throughput t (T) or a score S of traffic data for the terminal 105A. In one example, the computer <NUM> may be programmed to determine a data throughput t(T), e.g., in Mb/s, Gb/s, etc., of the terminal 105A, e.g., based on data analysis techniques, etc. The data throughput t(T) may include a unidirectional, e.g., sent out to the remote computer <NUM> by the terminal 105A. In another example, the computer <NUM> may be programmed, based on an equation (<NUM>), to determine a score S of the terminal 105A traffic load based on a data throughput t(T), and a data type quantifier QD. The function f<NUM> returns a score for the terminal 105A traffic load. The score S may be a number within a specified range, e.g., <NUM> to <NUM>. In one example, the function f<NUM> may be a linear function, e.g., S=aT + b QD, wherein parameters a and b are based on empirical methods. The computer <NUM> may be programmed to determine the data type quantifier QD based on equation (<NUM>). <MAT> <MAT>.

In the present context, a data quantifier QD is a measure to quantify data parameters which are relevant for a determination whether to communicate the data via terrestrial link <NUM> or satellite link <NUM>. In one example, the computer <NUM> may be programmed, based on equation (<NUM>), to determine the data quantifier QD based on data volume V and data priority P. The computer <NUM> may be programmed to determine the data volume V based on data received from a sender of the data, and/or other data analysis techniques. For example, the terminal 105A may determine a volume V of a bulk upload based on a data header transmitted at a beginning of a software update. The data volume V is volume, e.g., specified in Mb, Gb, etc., of data being transferred via the terminal 105A. For example, a volume V of a bulk upload is a volume of software downloaded from the remote computer <NUM> to a plurality of IoT devices <NUM>.

In the present context, data priority P is a measure for specifying a criticality of transferring the traffic data T without interruption and/or delay. Table <NUM> shows example levels of, data priority P. The computer <NUM> may be programmed to determine data priority P based at least in part on a latency threshold LT of the traffic data T. For example, the computer <NUM> may be programmed to determine a high priority level upon determining that a maximum latency threshold LT of the traffic data T is less than or equal <NUM> millisecond (ms). The computer <NUM> may be programmed to detect a type of traffic data T, e.g., using deep packet inspection, packet header classification, or other traffic classification techniques, and to determine the latency threshold LT based on the detected type of data.

Next, in a decision block <NUM>, the computer <NUM> determines whether a data throughput threshold DT and/or a score threshold ST is exceeded. In one example, the computer <NUM> may be programmed to determine whether the data throughput t(T) exceeds the data throughput threshold DT, e.g., <NUM> Mb/s. In another example, the computer <NUM> may be programmed to determine whether the terminal 105A score S exceeds a score threshold ST, e.g., <NUM>. The computer <NUM> may be programmed to store the score threshold ST in a computer <NUM> memory and/or to receive the score threshold ST from a second computer such as the remote computer <NUM>. If the computer <NUM> determines that the data throughput t(T) exceeds the data throughput threshold DT and/or the score S exceeds the score threshold ST, then the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> proceeds to a block <NUM>.

In the block <NUM>, the computer <NUM> identifies at least a portion Ts, of the traffic data to be routed via the satellite link <NUM> between the terminal 105A and a satellite <NUM>. The computer <NUM> routes a portion of the traffic data via the satellite link <NUM> to balance the traffic data T between the satellite link <NUM> and the terrestrial link <NUM>. In one example, the computer <NUM> may be programmed to determine the data portion Ts to be routed via the satellite link <NUM> based on the data throughput t(T), the threshold DT, and a capacity C of the satellite link <NUM>. In the present context, a data portion Ts includes a set of data, e.g., list of data packet identifiers, etc., that identifies specific parts of data from the traffic data. In the present context, t(Ts) returns a throughput of the data portion Ts. The computer <NUM> may determine the throughput of the data portion t(Ts) based on the identified data packets included in the data throughput portion Ts. For example, upon determining that the data portion Ts includes a data packet from IoT sensor <NUM> with a rate to be sent every second with a volume V of <NUM> megabit, the computer <NUM> determines that data portion throughput t(Ts) is <NUM> Mb/second (Mb/S). For example, the computer <NUM> may be programmed, based on equation (<NUM>) to determine the data portion Ts. In the present context, a capacity C of a satellite link <NUM> is a maximum data throughput, e.g., <NUM> Gb/s, that the respective satellite link <NUM> provides.

In another example, the computer <NUM> may be programmed to determine the data portion Ts for satellite link <NUM> based on the score threshold ST. For example, the computer <NUM> may be programmed to determine the data portion Ds such that SM=f<NUM>(T - TS, QD) < ST. In other words, the computer <NUM> may determine a portion of the traffic data such that a score of the data TT (i.e., the data T-Ds) routed via the terrestrial link <NUM> is less than the score threshold ST. For example, as shown in Table <NUM>, the computer <NUM> may be programmed to identify low priority portions of the traffic load, e.g., bulk upload data, for being routed via the satellite link <NUM>, such that the score SM of the data routed via the terrestrial link <NUM>, e.g., a mobile network, is below the score threshold ST. Thus, with reference to Table <NUM>, T - TS (or TT) represents a subtraction of a set of data Ts from another set of data, in contrast to an algebraic subtraction.

In the block <NUM>, the computer <NUM> may be programmed to route the data portion Ts via the satellite link <NUM> and the rest of data TT via the terrestrial link <NUM>. The computer <NUM> may actuate the satellite communication interface <NUM> and/or the terrestrial communication interface <NUM>, as discussed with reference to <FIG>, to route the data via the satellite and/or terrestrial links <NUM>, <NUM>. Routing of data by the terminal 105A computer <NUM> is further discussed with respect to <FIG>.

Following the block <NUM>, the process <NUM> ends, or alternatively returns to the block <NUM>, although not shown in <FIG>.

<FIG> shows a flowchart of another non-limiting example process <NUM> for balancing the data traffic on example rule <NUM> of Table <NUM>. The computer <NUM> may be programmed to execute blocks of the exemplary process <NUM>.

The process <NUM> begins in a block <NUM>, in which the computer <NUM> determines a data type quantifier QD, as discussed above.

Next, in a block <NUM>, the computer <NUM> determines a terrestrial link quantifier QM and a satellite link quantifier Qs for the terrestrial link(s) <NUM> and the satellite link <NUM> respectively. The link's quantifiers QM, Qs may be numbers within a specified range. , e.g., <NUM> to <NUM>. With reference to Table <NUM>, the computer <NUM> may be programmed to determine the link quantifiers QM, Qs based on a data rate capacity of the links <NUM>, <NUM>, link condition, e.g., weather conditions, , etc. In the present context, a link condition may be specified in percentage, e.g., <NUM>% is a perfect condition such as no rain, no wind, no physical obstacle, etc., whereas <NUM>% reflects a compromised link <NUM>, <NUM> condition such as inclement weather, etc. Table <NUM> shows a non-limiting example of quantifiers QM, Qs, capacity of link <NUM>, <NUM>, and a link condition. In one example, the computer <NUM> may be programmed to determine the quantifiers QM, Qs based on data stored in computer <NUM> memory such as Table <NUM>.

Next, in a block <NUM>, the computer <NUM> determines a terrestrial communication score SM and a satellite traffic data score Ss. The computer <NUM> may be programmed to determine the terrestrial traffic data score SM based on data portion TT routed through the terrestrial link <NUM> (e.g., T= TT, if the traffic data is routed entirely through the terrestrial link(s) <NUM> of the terminal 105A), the volume V of data, and the terrestrial link quantifier QM, e.g., based on equation (<NUM>). The computer <NUM> may be programmed to determine the satellite traffic data score Ss based on data throughput Ts, the volume V of data, and the satellite link quantifier Qs, e.g., based on equation (<NUM>). Equation (<NUM>) shows the relationship of traffic data T with portions TT and Ts routed through each of the terrestrial and satellite links <NUM>, <NUM>. <MAT> <MAT> <MAT>.

Typically, routing a large number of smaller data packets (i.e., lower volume V) via terrestrial link <NUM> has less overhead, e.g., establishing connection, etc., compared to routing same large number of smaller packets via satellite link <NUM>. Similarly, routing large volume V of data via satellite link <NUM> has less overhead compared to routing same data via terrestrial link <NUM>, e.g., mobile communication. In one example, the functions f<NUM>, f<NUM> may be specified such that transferring data T with small volumes V returns a lower score SM whereas returning a higher score Ss. For example, volume V may be a numerator in function fz whereas it is a denominator in the function f<NUM>.

Next, in a decision block <NUM>, the computer <NUM> determines whether the terrestrial score SM exceeds the satellite score Ss. If the computer <NUM> determines that the terrestrial score SM exceeds the satellite score Ss, then the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> proceeds to a block <NUM>.

In the block <NUM>, the computer <NUM> identifies data portion Ts and/or updates the data portion Ts (as discussed with reference to the block <NUM>). For example, the computer <NUM> may be programmed to identify the data portion Ts such that the terrestrial score SM is less than or equal the satellite score Ss. For example, the computer <NUM> may be programmed to modify the set of data Ts to increase a volume V of data Ts, e.g., by placing high volume V bulk upload in data portion Ts, as shown in Table <NUM>).

In the block <NUM>, the computer <NUM> routes the traffic load based on the identified data portion Ts for the satellite link <NUM>. The computer <NUM> may be programmed to route the data portion Ts via the satellite link <NUM> and to route the rest of data TT via the terrestrial link <NUM>. Further details of routing data are discussed below with reference to <FIG>.

<FIG> shows a system <NUM> including a plurality of terminals 105A, 105B, 105C and a plurality of IoT devices <NUM> communicating via the plurality of terminals 105A, 105B, 105C with the remote computer(s) <NUM>. In at least one example, terminals 105B and 105C (and their programming/operation) are similar or identical to terminal 105A; accordingly, these will not be re-described herein. While three terminals are shown in this figure, any suitable quantity of terminals may be used. The base station <NUM> and/or the multicast gateway (MCG <NUM>) may communicate with the remote computer <NUM> via the mobile backbone <NUM>, IP network <NUM>, etc., although not shown in <FIG>.

As discussed above, the traffic load may include data transmitted by the remote computer(s) <NUM> to the IoT devices <NUM>, e.g., a software update. In one example, synchronous software upgrade of the plurality of IoT devices <NUM> in the system <NUM> can be achieved using satellite <NUM> communication forward channel multicast (or broadcast) operation. In a forward channel multicast operation (or multicast mode), one set of data is sent to terminals 105A, 105B, 105C (i.e., a one-to-many communication) within coverage area <NUM> of satellite <NUM>, in contrast to a unicast communication (or communication in unicast mode) in which a one-to-one communication to each receiver is established. For example, a SDL (Software Downline Load) protocol can be used for a multicast software update. For example, the software update data packets can be uploaded via an uplink 145D to the satellite <NUM> and then transmitted concurrently in a multicast operation via downlinks 145A, 145B, 145C to the terminals 105A, 105B, 105C, e.g., via a beam that covers a geographical area in which the respective terminals are located. Typically, in a mobile backbone <NUM>, IP network <NUM>, data is transferred through unicast. As shown in <FIG>, a Multicast Gateway (MCG <NUM>) may operate as a router for the terminals 105A, 105B, 105C which participate in a multicast session. The satellite <NUM> gateway <NUM> may then receive multiple unicast streams from MCG <NUM> and select one of the received streams and transmit the selected stream via the satellite <NUM> beam, as further discussed with respect to <FIG>. MCG <NUM> typically keeps track of the terminals 105A, 105B, 105C that have joined a multicast session and determines a modulation and a coding scheme, as well as power level to reach all the terminals 105A, 150B, 105C.

In one example, remote computer <NUM> of a utility company managing a smart grid may deliver a command to a group of actuators IoT devices <NUM> by multicasting via MCG <NUM> and terminals 105A, 105B, 105C. Thus, by multicasting instead of delivering individual commands to each IoT device <NUM> via separate mobile terrestrial communication links <NUM>, signaling congestion and communication loads may be reduced. For multicasting purposes, devices <NUM> can be grouped based on which need the same downlink control messages (e.g., commands for actuators) and/or data packets (e.g., firmware/configuration or information file download). Additionally, or alternatively, the devices <NUM> can be grouped based on their service requirements (i.e. multicasting scenarios) or their physical location (i.e., geocasting scenarios), to reduce a signaling congestion on the air and/or to reduce the traffic load.

To protect satellite data communication against cyber-attacks, traffic data during a multicast is encrypted. In an encrypted unicast communication, a sender of data encrypts the data with an encryption key of a receiver and sends the encrypted data to the receiver. In one example, an encryption technique such as PKI (Public Key Infrastructure), etc. may be used. The receiver decrypts the received encrypted data based on the receiver's key, using known encryption techniques. However, an intruder computer may lack the encryption key of the receiver. Therefore, a cyber-attack may be prevented because the intruder computer, which eavesdrops decrypted data, cannot decrypt the encrypted data without possessing the encryption key.

Given an objective of achieving resource efficiencies by transmitting only one copy of data, e.g., via a spot beam, to reach multiple terminals 105A, 105B, 105C, which have joined a same multicast session, a unicast encryption technique may not be satisfactory, because each of the receivers of data (i.e., terminals 105A, 105B, 105C) may have a different encryption key. <FIG> is a sequence diagram <NUM> which illustrates a non-limiting example use case for multicasting encrypted data to a plurality of terminals 105A, 105B, 105C. The remote computer <NUM>, MCG <NUM>, satellite gateway <NUM>, and terminals 105A, 105B may be programmed to execute actions of the sequence diagram <NUM>. Although, the diagram <NUM> shows two terminals 105A, 105B, the disclosed method can be applied to any number of terminals 105A, 105B.

The sequence diagram <NUM> starts by terminals 105A, 105B performing a unicast security association with the gateway <NUM> (steps <NUM>, <NUM>). For example, the gateway <NUM> may communicate with each of the terminals 105A, 105B and receive the encryption key K1, K2 data of each of the terminals 105A, 105B. Thus, upon performing the unicast operations, the gateway <NUM> possesses encryption keys K1, K2.

Upon receiving an Internet Group Management Protocol (IGMP)join message (step <NUM>, <NUM>) from terminal 105A, the gateway computer <NUM> may transmit via the MCG <NUM> a PIM (Protocol Intendent Message) join message to the remote computer <NUM> (steps <NUM>, <NUM>, <NUM>). The IGMP is a communications protocol used to establish multicast group memberships. PIM is a family of multicast routing protocols for IP networks <NUM> that provide one-to-many and many-to-many distribution of data over an IP-based network.

The gateway computer <NUM> may generate a common key Km for a multicast session. As will be explained below, the generated common key Km will be same for all terminals 105A, 105B (of the session), thus preventing a need for unicast transmission of encrypted data to each respective terminal. The gateway computer <NUM> may distribute the multicast security key Km via a unicast communication to each of the terminals 105A, 105B using individual keys K1, K2 (step <NUM>). Thus, after receiving the distributed common key Km, each of the terminals 105A, 105B will be able to decrypt data encrypted with the common key Km.

The remote computer <NUM> may send multicast data packet P1 to the MCG <NUM> (step <NUM>). MCG <NUM> may transmit the message via an IP-based network through multiple unicast messages to the gateway <NUM> (steps <NUM>, <NUM>), whereas as shown in the diagram <NUM>, the gateway <NUM> will then select one of the streams, encrypt the data with the common key Km, and multicast the encrypted packet P1 to the terminals 105A, 105B (step <NUM>).

Upon receiving the encrypted multicast data, each of the terminals 105A, 105B may be programmed to decrypt the received multicast data based on the stored common key Km. Thus, the satellite <NUM> may multicast the data packet P1 to the plurality of terminals 105A, 105B, and each of those terminals 105A, 105B may concurrently receive the data, multicasted by the satellite <NUM>.

As discussed above, a condition of satellite link <NUM> may vary, e.g., based on weather condition, obstacles, etc. With reference to <FIG>, when satellite <NUM> multicasts data to the plurality of terminals 105A, 105B, 105C, a reception of different terminals 105A, 105B, 105C may differ. For example, terminal 105A may support a high spectral efficiency (i.e., high data rate for a given bandwidth) compared to terminal 105B. The satellite <NUM> computer <NUM> and/or the gateway <NUM> may be programmed to determine multicast parameters, e.g., data rate, frequency of the beam, etc., in accordance with a poorest link condition, i.e., such that the terminal with a lowest reception among the terminals 105A, 105B, 105C is expected to support the received multicast data.

Although this approach may be helpful in providing a possibility of multicasting data to the plurality of terminals 105A, 105B, 105C with a wide range of link conditions, power level, etc., but it may not be efficient because it may not utilize the terminals with a higher link condition, etc. In other words, by configuring the multicast based on low performing terminals (i.e., with lower link conditions), the satellite <NUM> may not utilize the terminals which support, e.g., higher data rate, frequency, etc..

In one example, discussed here below with reference to <FIG>, the terminals 105A, 105B, 105C may be divided into subgroups based on the respective link conditions, physical attributes, etc. In the present context, physical attributes of terminals 105A, 105B, 105C are specific parameters of the satellite communication interface <NUM>, antenna, etc., such as modulation, coding, power, etc. In the present context, a subgroup includes the plurality of terminals 105A, 105B, 105C being located within the coverage area <NUM> of the satellite <NUM> and being selected based on the respective physical attributes and/or link conditions.

<FIG> shows a sequence diagram <NUM> including a link adaptation portion <NUM>. With reference to the portion <NUM> of the diagram <NUM>, the satellite <NUM> computer <NUM> may be programmed to receive, via a satellite uplink <NUM>, a quality status RQ including a link condition, and to adjust, based on the received quality status RQ, at least one of multicast parameters including a data throughput, a transmission power, and a transmission spectral efficiency. Spectral efficiency is an information rate that can be transmitted over a given bandwidth in a specific communication system, e.g., measured in bit/s/Hz.

With reference to <FIG> and <FIG>, the sequence diagram <NUM> illustrates a similar sequence such as shown in <FIG> up to broadcasting the common encryption key Km to the terminals 105A, 105B (step <NUM>). However, after that step <NUM>, based on the sequence diagram <NUM>, the satellite <NUM> computer may adjust the multicast parameters based on quality status RQ received from the terminals 105A, 105B (steps <NUM>, <NUM>, <NUM>, <NUM>), as further discussed with reference to <FIG>.

<FIG> are a flowchart of a process <NUM> for operating satellite <NUM>. For example, a gateway computer <NUM> may be programmed to execute blocks of the process <NUM>.

The process <NUM> begins in a block <NUM> in which the gateway computer 180determines whether traffic data Ts is received from terminal(s) 105A, 105B, 105C, e.g., sensor data which terminals 105A, 105B, 105C received from IoT devices <NUM>. If the gateway computer <NUM> determines that traffic data is received from one or more terminals 105A, 105b, 105C, then the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> proceeds to a decision block <NUM>.

In the block <NUM>, the gateway computer <NUM> routes the traffic data Ts via satellite <NUM> downlink <NUM> to remote computer <NUM>, e.g., an IoT server. The gateway computer <NUM> may route the traffic data Ts via the gateway <NUM>, the mobile backbone <NUM>, and/or the IP network <NUM> to the remote computer <NUM>, e.g., an IoT server.

As discussed with reference to <FIG>, the traffic data T received from the terminals 105A, 105B, 105C may be split by the terminal 105A, 105B, 105C to data TT for terrestrial link <NUM> and data Ts for the satellite link <NUM>. A computer of the mobile backbone <NUM> may merge the traffic data TT received via the terrestrial link <NUM> and data Ts received from the satellite <NUM> downlink <NUM> in accordance with the determination of the respective terminal 105A, 105B, 105C to split the data (as discussed above with reference to the block <NUM> of <FIG>). Further, the computer of the mobile backbone <NUM> may split the traffic data going out from the remote computer <NUM> to the terminals 105A, 105B, 105C based on determination made at the terminal 105A, 105B, 105C, and/or determination made at the backbone <NUM> and/or gateway <NUM> on how to split the data transmitted to the terminals 105A, 105B, 105C between the links <NUM>, <NUM>. In one example, such determination may be made based on similar techniques discussed with respect to equations (<NUM>)-(<NUM>).

In the decision block <NUM>, the gateway computer <NUM> determines whether data is received from the remote computer <NUM> for multicast to terminals 105A, 105B, 105C. In other words, gateway computer <NUM> may determine whether a multicast session is needed. Additionally, or alternatively, the gateway computer 180may determine that a multicast session is needed based on IGMP join messages received from the terminals 105A, 105B, 105C (see <FIG>). The gateway computer 180may be programmed to communicate based on a PIM protocol with the remote computer <NUM>. If the gateway computer 180determines that data for multicast is received and/or IGMP join messages are received, then the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> proceeds to a decision block <NUM> (see <FIG>).

In the block <NUM>, the gateway computer <NUM> performs a unicast security association. The gateway computer <NUM> may be programmed to receive terminals 105A, 105B, 105C encryption keys K1, K2, K3 and store in gateway computer <NUM> memory. Additionally, or alternatively, the gateway computer <NUM> may be programmed to send a request for the encryption keys K1, K2, K3 to the terminals 105A, 105B, 105C, and to store the received keys K1, K2, K3.

Next, in a block <NUM>, the gateway computer <NUM> distributes the common key Km to the terminals 105A, 105B, 105C. The gateway computer <NUM> may be programmed to send the common key Km to each of the terminals 105A, 105B, 105C using the individual keys K1, K2, K3 of each terminal 105A, 105B, 105C.

Next, in a block <NUM>, gateway computer <NUM> transmits a request for a quality status RQ to each of the terminals 105A, 105B, 105C. For example, gateway computer <NUM> may be programmed to multicast a specified data to the terminals 105A, 105B, 105C with a set of different specified data rates, power levels, and frequencies. The specified data and/or the set of data rates, etc. may be stored in a gateway computer <NUM> memory.

Next, as shown in <FIG>, the gateway computer 180determines whether quality statuses RQ are received from the terminals 105A, 105B, 105C. In the present context, a quality status RQ of a terminal 105A, 105B, 105C includes information describing how successful satellite link <NUM> routes data between the satellite <NUM> and the respective terminal 105A, 105B, 105C. In one example, a quality status RQ describes the link condition. In one example, a quality status RQ includes a link condition specified in a percentage value. Additionally, or alternatively, the quality status RQ includes data such as a percentage of corrupted data received, etc. The gateway computer 180may store the quality status RQ of each of the terminals 105A, 105B, 105C in the gateway computer <NUM> memory, e.g., in a table. If the quality statuses quality status RQ are received, the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> returns to the decision block <NUM>. Alternatively, the process <NUM> may end or proceed without the quality status quality status RQ, although not shown in <FIG>.

In the block <NUM>, the gateway computer <NUM> determines groups of terminals 105A, 105B, 105C for multicast and further determines multicast parameters, e.g., data rate, spectral efficiency of the beam, etc., based on the received quality status RQ. For example, the gateway computer <NUM> may divide, based on the received quality status RQ, the terminals 105A, 105B, 105C into a first group of terminals 105A, 105C with a first set of multicast parameters and a second group of terminal(s) 105B with a second set of multicast parameters. For example, as shown in Table <NUM>, the gateway computer <NUM> may determine a first group having terminals 105A, 105C with quality status RQ values <NUM>% and <NUM>%, and a second group having the terminal 105B with quality status RQ value <NUM>%, based on the quality statuses RQ. In one example, the multicast of data with the first set and second set of multicast parameters may be via a same beam of the satellite <NUM>. In another example, multicasting of the data with the first and second set of parameters may be via a first and a second beam of the satellite <NUM> that overlap.

As shown in Table <NUM>, the gateway computer <NUM> may determine corresponding multicast parameters for each group, e.g., "High," and "Low". In an example, the gateway computer <NUM> may determine multicast parameters based on a table such as Table <NUM>. Table <NUM> shows an example for defining multicast parameters as a "High", "Medium", or "Low" level. Each of the levels may be associated with a specific data rate, spectral efficiency, etc. For example, power may be maintained constant but by changing modulation and/or coding data rate may be adjusted. The spectral efficiency is an indicator of modulation and coding scheme. As shown in Table <NUM>, the gateway computer <NUM> may determine the terminals 105A, 105C with a quality status RQ exceeding a quality threshold <NUM>% as a first group with multicast parameter "High" level, whereas determines the terminal 105B with the quality status RQ of <NUM>% (which is less than the threshold <NUM>% of Table <NUM>) as the second group with multicast parameter "low" level. Additionally, or alternatively, the computer may be programmed to group the terminals 105A, 105B, 105C based on other techniques, e.g., using statistical methods to identify groups with a deviation of quality status RQ less than a deviation threshold. Additionally, or alternatively, the gateway computer <NUM> may be programmed to determine the multicast parameters using other techniques, e.g., adjusting each of the data rate, power, etc., for a group based on an average quality statuses RQ received from the terminals 105A, 105B, 105C of the respective group.

Next, in a block <NUM>, the gateway computer <NUM> multicast the data to the terminals 105A, 105B, 105C based on the first set of multicast parameters via a first downlink <NUM>, and multicast the data based on the second set of multicast parameters via a second downlink <NUM>. For example, with respect to Table <NUM>, the gateway computer <NUM> may be programmed to multicast data with "high" level multicast parameters to the terminals 105A, 105B, and with the "low" multicast parameters to the terminal 105B. In one example, the first and second downlinks <NUM> may be included in a same beam of the satellite <NUM>. In another example, the first and second links <NUM> may be in different beam of the satellite <NUM>. Following the block <NUM>, the process <NUM> proceeds to a decision block <NUM> (see <FIG>).

With reference to <FIG>, following either of the blocks <NUM> of <FIG> or the block <NUM> of <FIG>, in the decision block <NUM>, the gateway computer <NUM> determines whether data is received from the remote computer <NUM> for terminal 105A, 105B, 105C. If the gateway computer <NUM> determines that data for transmitting to a terminal is received from the remote computer <NUM>, e.g., via the IP network <NUM>, backbone network <NUM>, etc., then the process <NUM> proceeds to a block <NUM>; otherwise, the process <NUM> ends, or alternatively returns to the block <NUM>, although not shown in <FIG>.

In the block <NUM>, the gateway computer <NUM> sends the received data to the respective terminal(s) 105A, 105B, 105C. The gateway computer <NUM> may determine the receiver terminal 105A, 105B, 105C of the data based on, e.g., header data including a terminal identifier, as discussed above with reference to <FIG>. Following the block <NUM>, the process <NUM> ends, or alternatively returns to the block <NUM>, although not shown in <FIG>. As another example, a satellite <NUM> computer <NUM> may be programmed to execute one or more blocks of the process <NUM>.

<FIG> show a flowchart of a process <NUM> for routing data via the terrestrial and satellite interfaces <NUM>, <NUM>. The process <NUM> specifies what may be performed in the blocks <NUM> or <NUM> of the processes <NUM>, <NUM> to route the traffic data T, e.g., by sending out IoT devices <NUM> data to the remote computer <NUM> and/or receiving traffic data from the remote computer <NUM> and sending the received data to the IoT devices <NUM>. For example, the terminal 105A computer <NUM> may be programmed to execute blocks of the process <NUM>.

The process <NUM> begins in a block <NUM>, in which the computer <NUM> performs unicast security association. The computer <NUM> may be programmed to exchange encrypted information with the satellite <NUM> computer <NUM> and/or the gateway <NUM> (see <FIG>) and provide the terminal 105A specific key K1 to the computer <NUM> and/or the gateway <NUM> computer.

Next, in a decision block <NUM>, the computer <NUM> determines whether a common encryption key Km is received. With further reference to <FIG>, the computer <NUM> may be programmed to receive a common key Km encrypted based on the terminal 105A key K1 via the satellite link 145A. If the computer <NUM> receives the common key Km, then the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> returns to the decision block <NUM>.

In the block <NUM>, the computer <NUM> stores the received common key Km in a computer <NUM> memory. As discussed below, the computer <NUM> may decrypt the data multicast by the satellite <NUM> based on the stored common key Km.

Next, in a decision block <NUM>, the computer <NUM> determines whether encrypted multicast data is received. The computer <NUM> may be programmed to determine whether the received data is multicast data based on various techniques, e.g., based on determining that the received data is addressed (e.g., based on the terminal identifier) for a plurality of terminals 105A, 105B, 105C rather than specifically being addressed for the terminal 105A. If the computer <NUM> determines that encrypted multicast data is received, then the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> proceeds to a decision block <NUM> (see <FIG>). Alternatively, the blocks <NUM> to <NUM> may be omitted, e.g., when no encrypted multicast is performed.

In the block <NUM>, the computer <NUM> decrypts the received encrypted data based on the received common key Km.

Next, in a block <NUM>, the computer <NUM> routes the decrypted data to the connected devices <NUM>. For example, the computer <NUM> may be programmed to route the decrypted data to a plurality of IoT devices <NUM> via a local communication network <NUM>. Non-limiting examples of locally-connected IoT devices <NUM> include temperature sensor, pressure sensors, utility company switching actuator, a programmable controller such as thermostat, etc. Following the block <NUM>, the process <NUM> proceeds to a decision block <NUM> (see <FIG>).

In the block <NUM>, the computer <NUM> determines whether a request for the quality status RQ is received. In one example, the request for quality status RQ may be a multicast message transmitted by the satellite to all terminals 105A, 105B, 105C. In another example, the request for quality status RQ may be a message individually addressed to the respective terminal 105A, 105B, 105C, e.g., including the terminal identifier. If the computer <NUM> determines that a request for quality status RQ is received, then the process <NUM> proceeds to a block <NUM>; otherwise the process <NUM> proceeds to a decision block <NUM>.

In the block <NUM>, the computer <NUM> determines the quality status RQ and sends the determined quality status RQ to the satellite <NUM>. The computer <NUM> may be programmed to determine the quality status RQ based on evaluating the communication via the satellite link 145A, e.g., determining link condition, etc. In one example, the computer <NUM> may store a table in the computer <NUM> memory that describes a relationship of quality status RQ with various parameters such as received power level, link condition, percentage of corrupted data, etc..

Next, in a decision block <NUM>, the computer <NUM> determines whether aggregating of traffic data for satellite link 145A is necessary. As discussed with respect to the function f<NUM> in equation (<NUM>), transmitting small packets of data may increase the score Ss. Upon determining that a number of small data packets (e.g., packets with a volume V less than a threshold, e.g., <NUM> kilobyte) exceeds a threshold, e.g., <NUM>, the computer <NUM> may be programmed to determine that the identified small packets may be aggregated to reduce the score Ss of the data being transmitted via the satellite link 145A.

In the block <NUM>, the computer <NUM> aggregates the identified data packets in an aggregated data packet including each of the small data packets. The computer <NUM> may be programmed to update the data portion TS for the satellite communication to replace the small data packets with the aggregated data packet. In one example, data aggregation may be implemented as a proxy server at satellite terminal 105A, 105B, 105C. In the present context, "updating" means replacing the small individual data packets from the data portion Ts and storing instead the aggregated data packet in the data portion Ts. Thus, by updating the data portion TS for the satellite communication, the satellite link <NUM> may be utilized more efficiently because by aggregating the data packets a volume V of the data portion Ts will be reduced.

Next, in a block <NUM>, the computer <NUM> may be programmed to transmit the identified data portion TS for satellite communication via the satellite link 145A. The computer <NUM> may be programmed to actuate the satellite communication interface <NUM> to route the data portions TS.

Next, in a block <NUM>, the computer <NUM> routes the rest of the data, i.e., the data portion TT for the terrestrial communication via the terrestrial link <NUM>. The computer <NUM> may be programmed to actuate the terrestrial communication interface <NUM> to transmit the data portion TT. Following the block <NUM>, the process <NUM> ends, or alternatively returns to the block <NUM>, although not shown in <FIG>.

Thus, there has been described a communication system that comprises a satellite terminal having a terrestrial communication interface, a satellite communication interface, and a computer. The terrestrial and satellite communication interfaces are configured to communicate traffic data. The satellite terminal system further includes a computer communicatively linked to the terrestrial and satellite communication interfaces. According to one example, a computer of the terminal system is programmed to determine that the traffic data, communicated via the terrestrial communication interface, exceeds a threshold, and based on the determination, route at least a portion of traffic data via the satellite communication interface in accordance with a predetermined traffic data load-balancing scheme.

According to another example, a satellite gateway computer may be programmed to receive, via a satellite uplink, a reception quality status including a link condition, and to adjust, based on the received quality status, at least one of multicast parameters including a data throughput, a transmission power, and a transmission spectral efficiency.

In general, the computing systems and/or devices described may employ any of a number of computer operating systems, including, but by no means limited to, versions and/or varieties of the Microsoft Windows® operating system, the Unix operating system (e.g., the Solaris® operating system distributed by Oracle Corporation of Redwood Shores, California), the AIX UNIX operating system distributed by International Business Machines of Armonk, New York, the Linux operating system, the Mac OSX and iOS operating systems distributed by Apple Inc. of Cupertino, California, the BlackBerry OS distributed by Blackberry, Ltd. of Waterloo, Canada, and the Android operating system developed by Google, Inc. and the Open Handset Alliance. Examples of computing devices include, without limitation, network devices such as a gateway or terminal, a computer workstation, a server, a desktop, notebook, laptop, or handheld computer, or some other computing system and/or device.

Computing devices generally include computer-executable instructions, where the instructions may be executable by one or more computing devices such as those listed above. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, Visual Basic®, Java Script®, Perl, etc. Some of these applications may be compiled and executed on a virtual machine, such as the Java Virtual Machine, the Dalvik virtual machine, or the like. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media.

A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including, but not limited to, non-volatile media and volatile media. Non-volatile media may include, for example, optical or magnetic disks and other persistent memory. Volatile media may include, for example, dynamic random-access memory (DRAM), which typically constitutes a main memory. Such instructions may be transmitted by one or more transmission media, including coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to a processor of a computer. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.

Databases, data repositories or other data stores described herein may include various kinds of mechanisms for storing, accessing, and retrieving various kinds of data, including a hierarchical database, a set of files in a file system, an application database in a proprietary format, a relational database management system (RDBMS), etc. Each such data store is generally included within a computing device employing a computer operating system such as one of those mentioned above, and are accessed via a network in any one or more of a variety of manners. A file system may be accessible from a computer operating system, and may include files stored in various formats. An RDBMS generally employs the Structured Query Language (SQL) in addition to a language for creating, storing, editing, and executing stored procedures, such as the PL/SQL language mentioned above.

In some examples, system elements may be implemented as computer-readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.), stored on computer readable media associated therewith (e.g., disks, memories, etc.). A computer program product may comprise such instructions stored on computer readable media for carrying out the functions described herein.

With regard to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments and should in no way be construed so as to limit the claims.

All terms used in the claims are intended to be given their ordinary meanings as understood by those knowledgeable in the technologies described herein unless an explicit indication to the contrary is made herein. In particular, use of the singular articles such as "a," "the," "said," etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.

Claim 1:
A system, comprising:
a plurality of terminals (105A, 105B);
a gateway computer (<NUM>), programmed to:
distribute an encryption key, in a unicast mode, to the plurality of terminals (105A, 105B);
receive traffic data from a remote computer (<NUM>); and
multicast the received traffic data to the plurality of terminals (105A, 105B) by:
encrypting the received traffic data with the encryption key; and
multicasting the received traffic data encrypted with the encryption key
to the plurality of terminals (105A, 105B);
wherein each of the plurality of terminals (105A, 105B) include:
a terrestrial communication interface (<NUM>);
a satellite communication interface (<NUM>), for satellite communication with the gateway computer (<NUM>) via a satellite link (<NUM>), wherein the terrestrial and satellite communication interfaces (<NUM>, <NUM>) are configured to communicate traffic data; and
a computer (<NUM>) communicatively linked to the terrestrial and satellite
communication interfaces (<NUM>,<NUM>), wherein the computer (<NUM>) determines that encrypted multicast data is received, wherein the computer executes instructions, to
determine that the traffic data, communicated via the terrestrial communication interface (<NUM>), exceeds a threshold; and
based on the determination, route at least a portion of traffic data via the satellite communication interface (<NUM>) in accordance with a traffic data load-balancing scheme.