Patent Description:
Cellular communication frequencies can vary within a range of <NUM> to <NUM> GigaHertz (GHz). Satellite communication frequencies can vary within a range of <NUM> to <NUM>. In the United States, as well as abroad, the local government may regulate radio frequency (RF) operations to mitigate RF interference-e.g., dedicating each of a plurality of frequency ranges (bands) to a specific purpose or type of transceiver. Non-limiting bands include a cellular band, a satellite band, a military band, etc..

US patent application <CIT> describes a satellite radiotelephone system that includes a space-based component that is configured to wirelessly communicate with first radiotelephones in a satellite footprint over a satellite radiotelephone frequency band, and an ancillary terrestrial network that is configured to wirelessly communicate with second radiotelephones in the satellite footprint over at least some of the satellite radiotelephone frequency band, to thereby terrestrially reuse the at least some of the satellite radiotelephone frequency band. Wireless radiation by the ancillary terrestrial network and/or the second radiotelephones at the space-based component is monitored, and the radiation by the ancillary terrestrial network and/or the plurality of second radiotelephones is adjusted in response to the monitoring. Intra-system interference and/or interference with other satellite systems thereby may be reduced or prevented.

International application <CIT> describes a method by which a level of interference to a wireless receiver may be controlled by determining a set of frequencies to be assigned to a wireless transmitter, responsive to an activity factor associated with the wireless transmitter, other than a transmission power level of the wireless transmitter. The set of frequencies is then assigned to the wireless transmitter.

Preferred features are set out in the dependent claims.

According to a first aspect of the claimed invention, a method comprises using a first long-range wireless communication (LRWC) mode, in a processor of a terminal having a software stack (<NUM>) that enables the terminal (<NUM>) to operate as a software defined radio (SDR), receiving or transmitting first wireless data using a carrier frequency; using a first set of dynamic parameters of layers in the software stack in the first LRWC mode; receiving a command to use a second LRWC mode upon determination that a subtended angle between a satellite (<NUM>, <NUM>) and a cellular node (<NUM>) is less than an alignment threshold; using the second LRWC, receiving or transmitting second wireless data using the same carrier frequency; and using a second set of dynamic parameters of layers in the software stack in the second LRWC mode, wherein the first set comprises at least one dynamic parameter that is different from each dynamic parameter in the second set; wherein the first LRWC mode is different than the second LRWC mode.

Optionally, the command is received from an orchestrator server.

Optionally, the instructions further comprise to control a directionality of the antenna when switching between the first and second LRWC modes.

Optionally, the instructions further comprise to: use a first set of dynamic parameters in the first LRWC mode; and use a second set of dynamic parameters in the second LRWC mode, wherein the first set comprises at least some values that are different from the second set.

Optionally, the first LRWC mode is a satellite mode, wherein the second LRWC mode is a cellular mode.

Optionally, the system further comprises an orchestrator server that commands the terminal and a plurality of other terminals to selectively switch between the first and second LRWC modes.

According to another aspect of the claimed invention a system comprises: an orchestrator server, comprising: a computer communicatively coupled to a satellite gateway and a cellular access network, the computer comprising: a processor; and memory, coupled to the processor, storing instructions executable by the processor, the instructions comprising, to: instruct a first terminal having a software stack that enables the terminal to operate as a software defined radio (SDR) to communicate wirelessly via a carrier frequency using a first long-range wireless communication (LRWC) mode wherein in the first LRWC mode the first terminal uses a first set of dynamic parameters of layers in the software stack; determine that, relative to the first terminal, a subtended angle between a satellite and a cellular node is less than an alignment threshold; and based on the determination, transmit a command to the first terminal to communicate wirelessly via the carrier frequency using a second LRWC mode, wherein the first LRWC mode is different that the second LRWC mode, wherein the first terminal uses a second set of dynamic parameters of layers in the software stack in the second LRWC mode, wherein the first set comprises at least one dynamic parameter that is different from each dynamic parameter in the second set.

Optionally the alignment threshold is two degrees.

Optionally the command further comprises the second set of dynamic parameters, for operation of the first terminal in the second LRWC mode.

Optionally the first LRWC mode is a satellite mode, wherein the second LRWC mode is a cellular mode.

Optionally the system further comprises the first terminal, wherein the first terminal is programmed to transmit or receive first wireless data via the first LRWC mode using the carrier frequency and also to transmit or receive second wireless data via the second LRWC mode using the carrier frequency.

Optionally the instructions further comprise: repeating the instructions to instruct, determine, and transmit for a plurality of terminals, wherein the plurality of terminals includes the first terminal.

Optionally the instructions further comprise: transmitting the commands to each of the plurality of terminals based on availability of a plurality of system resources, wherein the plurality of system resources includes one or more satellites, one or more cellular nodes of the cellular access network, and the satellite gateway.

Optionally the instructions further comprise: commanding at least some of the plurality of terminals to switch between the first and second LRWC modes based on current wireless traffic data, wireless traffic trend data, or both.

Optionally the instructions further comprise: negotiating with a second orchestrator server to exchange system resources using a secure transaction technique.

Any of the instruction aspects set forth above may be combined with one another according to any suitable combination.

Any of the method aspects set forth above may be combined with one another according to any suitable combination.

With reference to the figures wherein like reference numerals denote identical or like features or elements, a telecommunication system <NUM> is shown in <FIG> that includes a multi-mode terminal <NUM> that communicates (wirelessly transmits and/or receives) by selectively operating in at least one of two different modes-e.g., such as selectively switching back and forth between a first long-range wireless communication (LRWC) mode (e.g., a satellite mode) and a second LRWC mode (e.g., a cellular mode). More particularly, the terminal <NUM> may be programmed to communicate in the first and second LRWC modes using a common frequency (e.g., a common carrier frequency). As will be described more below, using system <NUM>, terminal <NUM> wirelessly may communicate cellular data at higher data rates and/or may be enabled to communicate data over a variety of wireless communication links (or simply referred to a `wireless links')-e.g., communicating over a second wireless link (e.g., a cellular link) when network congestion exceeds a threshold over a first wireless link (e.g., a satellite link), or vice-versa. As will be described more below, terminal <NUM> may be instructed when to switch between the first and second wireless communication modes by one or more remotely-located computing devices.

Below, an illustrative example of system <NUM> is described. Thereafter, illustrative examples of computer-executable processes are described, wherein the processes use elements of the system <NUM>. It should be appreciated that the context of the description below pertains to fifth generation (<NUM>) telecommunication, wherein <NUM> networks are expected to require significantly more radio frequency (RF) spectrum than fourth generation (<NUM>) and other existing technologies. For example, satellite communication currently utilizes bands up to <NUM> and-in a <NUM> context, may be expanding to even higher radio frequency bands. For these higher bands, antenna directivity is more relevant, and as disclosed below, directional links may be used to reduce path and propagation losses.

<FIG> illustrates the telecommunication system <NUM> comprising at least one orbiting device <NUM> and a plurality of terrestrial devices <NUM>. In the illustrated system <NUM>, the at least one orbiting device <NUM> comprises a constellation of satellites <NUM>, <NUM>, <NUM>, <NUM>. Further, in the illustrated system <NUM>, the plurality of terrestrial devices <NUM> comprise: one or more terminals <NUM> (only one is shown for illustration purposes), at least one satellite gateway <NUM> (again, only one is shown for illustration purposes) that can communicate with the terminal <NUM> via at least one of satellites <NUM>-<NUM>, at least one cellular access network (AN) <NUM> (only one is shown for sake of illustration purposes) that can communicate with the terminal <NUM>, a core network (CN) <NUM> that can be communicatively coupled to the satellite gateway <NUM>, and the cellular gateway <NUM>, and an orchestrator server <NUM>. In <FIG>, the server <NUM> may be used to, among other things, determine when terminals <NUM> should switch between one of a plurality of LRWC modes; server <NUM> is shown communicatively coupled between the satellite gateway <NUM> and the core network <NUM>; however, as will be apparent from the description below, this communicative coupling arrangement is merely an example.

Orbiting device <NUM> may refer to any electro-mechanical machine having orbital motion above a threshold altitude-i.e., orbital motion refers to having gravitational-influenced motion around the Earth. Non-limiting examples of threshold altitudes include altitudes above sea level of: <NUM> kilometers (km), <NUM>, <NUM>, <NUM>,<NUM>, <NUM>,<NUM>, <NUM>,<NUM>, and the like. Further, by way of example, the orbiting device <NUM> may travel in a Geo-Synchronous-earth Orbit (GSO) or a Non-Geo-Synchronous-earth Orbit (NGSO). Further, GSO orbiting devices may include those devices traveling in Geostationary Equatorial Orbits (GEOs); however, this is not required. Still further, orbiting devices <NUM> can include those traveling in a Low Earth Orbit (LEO), a Medium Earth Orbit (MEO), a High Earth Orbit (HEO), or any other suitable orbit above, below, or therebetween. According to one example, orbiting device <NUM> may include pseudo-satellites (High-Altitude Pseudo-Satellites), aircraft, blimps, and balloons.

In at least one example, each of satellites <NUM>-<NUM> may be identical; therefore, only one will be described. Satellite <NUM> may comprise any suitable arrangement of electronics, including but not limited to, power electronics, onboard computer(s), antenna(s), transmitter(s), receiver(s), and the like-interconnected to provide power and communication to its various components and sub-components. In at least one example, the satellite <NUM> comprises a so-called bent pipe architecture-e.g., functioning to relay information between terminal <NUM> and satellite gateways <NUM>. According to one example, satellite <NUM> is located within a GEO. Thus, as will be explained in greater detail below, a terrestrial observer would perceive satellite <NUM> to be in a substantially fixed position in the sky. According to another example, satellite <NUM> is located within a GSO (but not a GEO). And according to yet another example, satellite <NUM> is located within a NGSO.

Turning to the terrestrial devices <NUM> (and more particularly, terminal <NUM>), as used herein, a terminal is an electronic device which is configured to communicate via a plurality of different long-range wireless communication (LRWC) modes. As used herein, a long-range wireless communication (LRWC) mode refers to a node-to-node wireless link larger than <NUM> meters. As discussed above, two non-limiting examples of LRWC modes include a cellular mode and a satellite mode; however, other examples exist.

<FIG> illustrates that terminal <NUM> may comprise a computer <NUM>, an antenna <NUM>, a radio frequency (RF) front end <NUM>, a signal converter <NUM>, a channelizer and sampling rate converter <NUM>, and a baseband processing unit <NUM>. Each will be discussed in turn below. Non-limiting examples of terminal <NUM> include a user terminal and a backhaul terminal. For example, a backhaul terminal is a terminal that may connect to a terrestrial tower (e.g., cellular)-e.g., not having connectivity to a core network. According to one example, via such a backhaul terminal (and also via a satellite and satellite gateway), a terrestrial tower may be connected to the core network.

Computer <NUM> of terminal <NUM> comprises at least one processor <NUM> (only one is shown for purposes of illustration) and memory <NUM>. Processor <NUM> may be any arrangement of electronic components capable of carrying out the methods described herein. Non-limiting examples of processor <NUM> include a microprocessor, a microcontroller or controller, an application specific integrated circuit (ASIC), etc. just to name a few. In general, computer <NUM> may be programmed to execute (via the processor <NUM>) digitally-stored instructions, which may be stored in memory <NUM>, which enable the computer <NUM>, among other things, to: steer a beam of the directional antenna; based on a direction of the beam, and using a first LRWC mode, receive or transmit first wireless data using a carrier frequency; and using a second LRWC mode, receive or transmit second wireless data, via a second wireless link, using the same carrier frequency, wherein the first LRWC mode is different than the second LRWC mode. This is merely one exemplary set of instructions; other instructions exist which may be executed in addition to and/or instead of these exemplary instructions-including those instructions which are described below and shown by way of example in the flow diagrams.

Memory <NUM> may include any non-transitory computer usable or readable medium, which may include one or more storage devices or articles. Exemplary non-transitory computer usable storage devices include conventional hard disk, solid-state memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), as well as any other volatile or non-volatile media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory, and volatile media, for example, also may include dynamic random-access memory (DRAM). These storage devices are non-limiting examples; e.g., other forms of computer-readable media exist and include magnetic media, compact disc ROM (CD-ROMs), digital video disc (DVDs), other optical media, any suitable memory chip or cartridge, or any other medium from which a computer can read. As discussed above, memory <NUM> may store one or more computer program products which may be embodied as software, firmware, or other programming instructions executable by the processor <NUM>-including but not limited to the instruction examples set forth above.

Antenna <NUM> may comprise any suitable hardware and/or software (or firmware and/or the like) adapted to receive radio wave signals for data processing and/or to transmit radio wave signals received from signal-processing components internal to the terminal <NUM>. Antenna <NUM> may operate in an omnidirectional mode or a directional mode. And in at least one example, antenna <NUM> operates in both omnidirectional and directional modes. As used herein, a directional mode refers to: (a) when transmitting, focusing radio wave density in a predetermined direction via a beam (e.g., a beam can be also referred to as a `lobe'); and (b) when receiving, focusing radio wave reception in a predetermined direction via a beam. As used herein, an omnidirectional mode refers to transmitting or receiving without regard to direction (i.e., not in a directional mode); thus, to cite a couple examples, operating in an omnidirectional mode can include transmitting equally in all directions and/or receiving equally in all directions. In at least one example, antenna <NUM> comprises a phased-array antenna-e.g., comprising a plurality of antenna elements, wherein each element is typically coupled to a phase-shift driver (not shown) so that each antenna element can be selectively controlled to control a direction of the antenna's beam. This is merely an example; other directional antenna examples exist. In at least one example, antenna <NUM> is adapted to operate within a frequency range of <NUM> to <NUM> (e.g., including L band, S band, Ku band, Ka band, and the Extremely High Frequency (EHF) band).

RF front end <NUM> may include any suitable arrangement of RF filters, RF amplifiers, mixer(s), local oscillator(s), and/or intermediate filters. Front end <NUM> will not be described in great detail here, as these elements and their arrangements are known in the art.

Signal converter <NUM> may include any suitable conversion hardware and/or software to convert analog signals to digital signals and vice-versa. <FIG> illustrates that the converter <NUM> comprises, for radio signals received via antenna <NUM>, an analog-to-digital converter (ADC) <NUM>; and <FIG> illustrates that the converter <NUM> comprises, for radio signals being transmitted from antenna <NUM>, a digital-to-analog converter (DAC) <NUM>. Any suitable ADCs and DACs may be used including those implemented via electronic circuit components, via software, or a combination thereof.

Channelizer and sampling rate converter <NUM> may include suitable conversion hardware and/or software for channelization and sampling rate conversion of incoming or outgoing communications. For example, for receiving wireless data (via ADC <NUM>), converter <NUM>, among other things, may determine a center frequency and perform additional filtering, frequency-conversion, down-sampling, and data packet extraction. And for example, for transmitting wireless data, converter <NUM>, among other things, may perform a reverse operation (using packet data to be transmitted), and converter <NUM> may deliver this processed data to DAC <NUM>.

Baseband processing unit (BPU) <NUM> also may include any suitable electronic hardware <NUM> and/or a software <NUM> that is configured to manage multiple radio functions (i.e., those which require antenna <NUM>). Non-limiting examples of hardware <NUM> include any suitable combination and arrangement of field-programmable gate arrays (FPGAs), discrete signal processing (DSP) units, application specific integrated circuits (ASICs), and the like. Non-limiting examples of software <NUM> utilize and or comprise any suitable combination of algorithms, middleware (i.e., software that bridges an operating system (OS) and application software and/or databases), common object request broker architecture (CORBA), virtual radio machines, or the like.

According to at least one example, using the preceding components, the terminal <NUM> may operate as a so-called Software Defined Radio (SDR). SDR systems replace at least some traditional radio components with tailored software (e.g., at least a portion of signal converter <NUM>, channelizer and sampling rate converter <NUM>, and/or BPU <NUM> may be implemented in software as part of the SDR). In this manner, terminal <NUM> may serve as a dynamic transmitter and/or a dynamic receiver-capable of using components <NUM>-<NUM> to wirelessly communicate via both a cellular protocol and a satellite protocol via a common predetermined carrier frequency.

<FIG> further illustrates that computer <NUM> may be communicatively coupled to antenna <NUM> so that processor <NUM> may control the antenna mode (as well as antenna directionality, as appropriate) and that computer <NUM> may be communicatively coupled to BPU <NUM> so that processor <NUM> may control a plurality of parameters of the BPU <NUM> to dynamically utilize the terminal <NUM> via different LRWC modes, as explained more below (following a discussion of the terminal's software stack). <FIG> illustrates that computer <NUM> (optionally) may be communicatively coupled to the signal converter <NUM> and/or the channelizer and sampling rate converter <NUM> as well-e.g., to control computer-implemented operations thereof.

Turning to <FIG>, an example software stack <NUM> of terminal <NUM> is shown (e.g., according to the Open Systems Interconnection (OSI) model). For example, stack <NUM> may comprise a Non-Access Stratum layer <NUM>, a Radio Resource Control (RRC) layer <NUM>, a Service Data Adaption Protocol (SDAP) layer <NUM>, a Packet Data Convergence Protocol (PDCP) layer <NUM>, a Radio Link Control (RLC) layer <NUM>, a Media Access Control (MAC) layer <NUM>, and a Physical (PHY) layer <NUM>. According to at least one example, in a fifth generation (<NUM>) implementation, a NAS layer <NUM> may comprise a functional layer in cellular telecom protocol stacks to enable communication between the core network <NUM> and the terminal <NUM>. According to at least one example, in a <NUM> implementation, the RRC layer <NUM> includes a cellular communication protocol defined by the <NUM>rd Generation Partnership Project (3GPP). According to at least one example, in a <NUM> implementation, the SDAP layer <NUM> may function to map between a quality of service (QoS) flow and a data radio bearer. According to at least one example, in a <NUM> implementation, the PDCP layer <NUM> may function to: transfer data between a user plane and control plane, maintain PDCP sequence numbers, perform header compression and decompression, cipher and decipher, etc. According to at least one example, in a <NUM> implementation, the RLC layer <NUM> may function to: transfer upper layer protocol data units (PDUs), sequence numbering, re-establish RLC, etc. According to at least one example, in a <NUM> implementation, the MAC layer <NUM> may function to: transfer upper layer protocol data units (PDUs), sequence numbering, re-establish RLC, etc. According to at least one example, in a <NUM> implementation, the PHY layer <NUM> may comprise any hardware, electronic circuitry, etc. suitable to implement the functions of the terminal <NUM>, as described herein.

In order to dynamically utilize the terminal <NUM> via different LRWC modes, one or more parameters of at least some of the layers in the software stack <NUM> of terminal <NUM> may be dynamically interchanged (e.g., for these dynamic parameters: a first set of values for operation in a cellular mode and a second set of values for operation in a satellite mode). A set of dynamic parameters may include, among other examples, an RRC timer parameter. For example, in a cellular mode, the RRC timer parameter may have a value of <NUM> milliseconds (ms), whereas in a satellite mode, the RRC timer parameter may have a value of <NUM> (e.g., for a GEO satellite system). And/or for example, an RLC layer timer t_pollRetransmit may be as little as <NUM>, whereas in a satellite mode, the RLC layer timer t_pollRetransmit may be as little as <NUM>. As will be explained more below, these and other dynamic parameters (and respective values associated therewith) may be broadcasted to the terminal <NUM> at a time the terminal <NUM> connects to a satellite gateway <NUM> and/or cellular gateway <NUM>. Of course, other examples also exist (e.g., any suitable values instead could be stored in memory <NUM> of terminal <NUM>). Using these dynamic parameters, terminal <NUM> may seamlessly switch between the cellular mode and the satellite mode.

As shown in <FIG>, satellite gateway <NUM> may comprise a computer <NUM> and a satellite transceiver <NUM>. Computer <NUM> may comprise any suitable components (not shown) including one or more processors, one or more memory devices, or the like-e.g., similar to those described above, but of course configured and/or programmed to carry out instructions regarding satellite communications and intercommunications with the cellular access network <NUM>, core network <NUM>, and/or other various backend services. Transceiver <NUM> may comprise an antenna coupled to any suitable signal processing hardware and software configured to send and receive satellite data via satellites <NUM>-<NUM> (transceiver components not shown).

<FIG> illustrates that satellite gateway <NUM> comprises a software stack <NUM> that corresponds with the software stack <NUM> (of terminal <NUM>). Among other layers, software stack <NUM> may comprise an RRC layer <NUM>, an SDAP layer <NUM>, a PDCP layer <NUM>, an RLC layer <NUM>, a MAC layer <NUM>, and a PHY layer <NUM>-which correspond with layers <NUM>-<NUM>, respectively. As these layers may have similar functions except that they are implemented in satellite gateway <NUM>, they will not be described in greater detail here. <FIG> illustrates that RRC layers <NUM>, <NUM> may be communicatively coupled; SDAP layers <NUM>, <NUM> may be communicatively coupled; PDCP layers <NUM>, <NUM> may be communicatively coupled; RLC layers <NUM>, <NUM> may be communicatively coupled; MAC layers <NUM>, <NUM> may be communicatively coupled; and PHY layers <NUM>, <NUM> may be communicatively coupled.

As shown in <FIG> and <FIG>, cellular access network (AN) <NUM> may comprise a <NUM> New Radio (NR) implementation. For example, AN <NUM> may comprise multiple cellular next generation eNodeB nodes (ng-eNB) <NUM> and multiple next generation NodeB nodes (gNB) <NUM> (one of each is shown only for purposes of illustration; of course, more of either may be used instead). Nodes <NUM>, <NUM> may communicate with one another via a control interface (Xn) link, and via the same type of link, nodes <NUM>, <NUM> may communicate with satellite gateway <NUM>. Further, nodes <NUM>, <NUM> may communicate with the core network (CN) <NUM> via next generation user plane and next generation control plane links (NG-U link and NG-C link, respectively). Xn, NG-U, and NG-C links may be wired, wireless, or a combination thereof.

Core network (CN) <NUM>-as shown in <FIG>, <FIG>, and <FIG>-may comprise any suitable telecommunication network facilitating communication between network or sub-networks. In the illustrations, it is shown by way of example to be a <NUM> core network; however, this is merely an example. As best shown in <FIG>, CN <NUM> may comprise a Core Access and Mobility Management Function (AMF) <NUM> (comprising NAS layer <NUM>), a User Plane Function (UPF) <NUM> (comprising Protocol Data Unit (PDU) Handling <NUM>), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Repository Function (NRF), a Unified Data Management (UDM), an Authentication Server Function (AUSF), a Policy Control Function (PCF), an Application Function (AF), and a Session Management Function (SMF), among other things.

AMF <NUM> may support termination of NAS signaling, NAS ciphering and integrity, registration management, connection management, mobility management, access authentication and authorization, security context management, and the like. As shown in <FIG>, AMF <NUM> may communicate with satellite gateway <NUM> via a NG-C link, with SDAP <NUM> (of gateway <NUM>) via a NG-U link, and with cellular AN <NUM> via a NG-U link.

UPF <NUM> may support packet routing and forwarding, packet inspection, and quality of service (QoS) handling. Further, UPF <NUM> may act as an external PDU session point of interconnect to data networks (DNs) and may be an anchor point for intra- and inter-radio access technology (RAT) mobility. UPF <NUM> may communicate with cellular AN <NUM> via a NG-Clink.

Orchestrator server <NUM> is shown in at least <FIG> and <FIG> and is configured to control switching of multiple terminals <NUM> between first and second LRWC modes using satellite gateways <NUM>, cellular AN <NUM>, other infrastructure or devices, or a combination thereof. According to one example, server <NUM> comprises a computer <NUM> and one or more databases <NUM>. Computer <NUM> may comprise one or more processors <NUM> and memory <NUM>. Processor(s) <NUM> and memory <NUM> may be similar to the processor and memory described above, except that memory <NUM> (and/or processor(s) <NUM>) may store different instructions and these different instructions may be executable by processor(s) <NUM> (instead of by processor(s) <NUM>). Databases <NUM> may store, among other things, information regarding multiple terminals (such as terminal <NUM>), satellites <NUM>, satellite gateways <NUM>, cellular AN <NUM>, or the like. Further, databases <NUM> may store usage information-e.g., indicating data traffic patterns over cellular communication links, as well as data traffic patterns over satellite communication links. Processor(s) <NUM> may parse databases <NUM> and memory <NUM> and utilize any such information to carry out any portion of the methods described herein.

According to one example, server <NUM> may facilitate-e.g., via the satellite gateway <NUM> and/or cellular gateway <NUM>-how and when terminal <NUM> switches between the different long-range wireless communication (LRWC) modes (e.g., between cellular and satellite modes). Server <NUM> may be used to increase spectrum sharing, thereby utilizing unused resources across a diversity of platforms and telecommunication systems; e.g., using real-time analysis of spatial and temporal traffic demands, geometrical considerations regarding line-of-sight signal propagation based on radio path characteristics, historical resource usage information, regulatory constraints, and trajectory models of mobile platforms. Accordingly, server <NUM> may instruct terminals <NUM> to switch LRWC modes, as will be described more below. Additional examples of server <NUM> will be described more below. In at least one example, server <NUM> forms part of satellite gateway <NUM> (e.g., <FIG> illustrates an orchestrator system <NUM> that comprises satellite gateway <NUM> and orchestrator server <NUM>).

According to one example, server <NUM> may be programmed and/or configured to maintain awareness of resources used by diverse systems; e.g., wherein each system is capable of tracking locations and mobility of its platforms, the beams and/or coverage data, and respective unused frequency resources (including time durations).

<FIG> illustrates a schematic diagram of an illustrative environment of a spectrum sharing approach, wherein server <NUM> is positioned centrally with respect to a first set S(<NUM>) of repeatedly-updated information, another set S(n) of repeatedly-updated information, and a set of static information (ST). [It is contemplated that any suitable quantity of sets of repeatedly-updated information may be used-e.g., while not all shown here, S(<NUM>), S(<NUM>), S(<NUM>),.

Set S(<NUM>) may comprise data from a first system such as a satellite network (e.g., received via satellite gateway <NUM>). Non-limiting data types may include unused resources data <NUM>, resource demand data <NUM>, platform location data <NUM> (of terminals <NUM>, satellite-only terminals, etc.), and current traffic data <NUM>.

Set S(<NUM>) may comprise data from a second system such as a cellular network (e.g., received via cellular access network <NUM>-e.g., via one or more nodes <NUM>, <NUM> or the like). Non-limiting data types may include unused resources data <NUM>, resource demand data <NUM>, platform location data <NUM> (of terminals <NUM>, cellular-only terminals, etc.), and current traffic data <NUM>.

Set ST may comprise data pertinent to either the satellite network or the cellular network, but which does not typically change regularly or during the course of a day. Non-limiting data types may include International Telecommunication Union (ITU) regulation data <NUM>, host nation agreement data <NUM>, antenna configuration data <NUM> (e.g., of terminal <NUM>), gateway antenna configuration data <NUM> (e.g., transceiver <NUM>), and service plan data <NUM>.

<FIG> illustrates a multi-tiered resource orchestration-e.g., usable by the orchestrator server <NUM>, the cellular gateway <NUM> (e.g., cellular nodes <NUM>, <NUM>), and/or the satellite gateway <NUM>. In this manner, the server <NUM> may receive information regarding cellular resources (e.g., from cellular gateway <NUM>), determine whether to communicate with the satellite gateway <NUM> (e.g., to advise regarding such sharable resources-e.g., resources such as share-able frequencies), and then facilitate such a transaction. Server <NUM> of course, may execute the reverse-e.g., determine that satellite resources are available (e.g., from satellite gateway <NUM>), determine whether to communicate with the cellular gateway <NUM>, and then facilitate the transaction. For example, using a data link layer, cellular node <NUM>, <NUM> may receive information from server <NUM> and schedule transmissions in time and frequency domains (including a mix of MF-TDMA, FDMA, CDMA, and/or OFDM schemes). And using a physical layer, cellular node <NUM>, <NUM> may select specific power levels consistent with predetermined constraints stored at the server <NUM>. In some instances, higher signal transmission power can be used-improving spectral efficiency of modulation schemes and thereby resulting in higher data rates. Networking across the physical layer (e.g., cellular nodes <NUM>, <NUM> and server <NUM>) can enable coordination diverse transports and respective platforms.

As described above, a location of terminal <NUM> may be fixed in some instances; however, in other instances, it may not be. When the terminal <NUM> is mobile, server <NUM> may need additional information to determine when it should transmit and/or receive data over a first LRWC mode versus a second LRWC mode. Further, a mobile terminal may require information regarding where to orient its respective antennas. <FIG> is a model that illustrates overlap between a management plane <NUM> and a control plane <NUM>; this model is suitable for any communication platform of the above-described system <NUM> (e.g., platforms such as terminal <NUM>, ng-eNB node <NUM>, gNB node <NUM>, and/or satellite gateway <NUM>).

Management plane <NUM> comprises data collection <NUM>, decision-making <NUM>, dissemination <NUM>, and resource exchange <NUM>. Management plane <NUM> further may comprise a portion <NUM> for server <NUM> orchestration that includes: data collection <NUM>, decision-making <NUM>, dissemination <NUM>, and resource exchange <NUM> and a frame level <NUM>. The control plane <NUM> which overlaps the management plane <NUM> may comprise data collection <NUM>, decision-making <NUM>, dissemination <NUM>, and resource exchange <NUM> and for a plurality of control iterations from <NUM> to Nc. As illustrated by <NUM>, <NUM>, and <NUM>, orchestrator server <NUM> sends and/or receives information relative to <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, respectively.

<FIG> further illustrates a Time Domain Multiple Access (TDMA) context (however, a CDMA, FDMA, etc. context could be used in other examples). For example, time parameters TM, Tc, and TF may refer to a tier of three elements-the management plane (`M'), the control plane (`C'), and the data plane (`F'), respectively. As illustrated in the figure, the management plane may be the slowest, the control plane may be faster than the management plane, and the data plane may be faster than the control plane (e.g., TM > Tc > TF). A typical management plane cycle may comprise multiple control plane cycles-e.g., the control plane cycle for the cellular gateway <NUM> may be <NUM> (e.g., frame size), whereas the control plane cycle for the satellite gateway <NUM> may be <NUM>. In this example, server <NUM> could receive this information from each of the satellite and cellular gateways <NUM>, <NUM> and determine that a synchronization setting of <NUM> (<NUM> x <NUM>) is feasible. This synchronization setting may be a lowest usable frame level (e.g., lowest common multiple). Further, TM may equal Nc * Tc, wherein Nc is a number that determines a periodicity within which different tiers operate, Tc is a lowest common multiple of a quantity of TDMA frame sizes. It should be appreciated that Nc may be a relatively large number for management tier (TM) and a relatively small number for data tier (TF).

Server <NUM> can determine a terminal's (<NUM>) antenna directivity using a so-called two-line element (TLE) technique for a time-based estimate of terminal <NUM>'s position (and velocity, if terminal <NUM> is mobile).

Turning to <FIG>, a process <NUM> is illustrated that may be executed independently by each of satellite gateway <NUM> (e.g., via a so-called 'hub' thereof) and cellular gateway (e.g., cellular nodes <NUM>, <NUM>) thereby facilitating orchestration interaction between terminal <NUM>, the satellite gateway <NUM>, and/or the cellular node <NUM>, <NUM>. Before describing computer-executable instruction blocks <NUM>, <NUM>, <NUM>, and <NUM>, it will be appreciated that some previously-illustrated elements are shown (from <FIG>), as well as some new elements (platform analytics data <NUM>, expected resource usage data per location <NUM>, historical traffic data <NUM>, expected resource usage data per location and time <NUM>, wherein examples of resources are frequency, power, and direction, wherein examples of service plan data are data rate, location of a platform, and time).

As either of satellite gateway <NUM> or cellular gateway <NUM> may execute the process <NUM>, by way of example only, gateway <NUM> will be used to illustrate the process implementation (e.g., however, the same steps can be taken by cellular gateway <NUM> independent of and/or at least partially concurrently with those of satellite gateway <NUM>). In block <NUM>, satellite gateway <NUM> may analyze regulatory frequency assignments per generated location specific frequency and power availability maps. This may comprise receiving input from ITU regulation data <NUM> and host nation agreement data <NUM>.

Following block <NUM>, process <NUM> may proceed to block <NUM>, wherein satellite gateway <NUM> may analyze system antenna beam patterns (from one or more terminals <NUM>), RF design and implementation constraints to baseline resource usage for the system <NUM>. This may include receiving input such as terminal antenna configuration data <NUM> (regarding terminal antennas <NUM>), gateway antenna configuration data <NUM>, and platform analytics data <NUM> (data analytics regarding terminals <NUM>).

The output of block <NUM> may be used to determine expected resource usage data per location <NUM>. And the output of block <NUM> may be provided to block <NUM>.

In block <NUM>, satellite gateway <NUM> may analyze customer service expectations and historical traffic per location to create a high-level resource usage plan per location and time. Thus, additional inputs to block <NUM> may comprise service plan data <NUM> and historical traffic data <NUM>.

In block <NUM> which follows, satellite gateway <NUM> may determine expected resource usage data per location and time, and in block <NUM>, this expected resource usage data per location and time may be transmitted to the orchestrator server <NUM> where it may be used by server <NUM> to instruct terminals <NUM> to selectively switch between satellite and cellular modes.

Turning now to <FIG>, a process <NUM> executed by server <NUM> is illustrated-e.g., upon receipt of this expected resource usage data per location and time <NUM> from both satellite and cellular gateways <NUM>, <NUM>.

<FIG> illustrates server <NUM> receiving, from satellite and cellular gateways <NUM>, <NUM>, expected resource usage data per location and time <NUM> (via block <NUM>) and aggregating and storing this data (e.g., in database <NUM>). This expected resource usage data per location and time regarding multiple terminals <NUM> is used in block <NUM>.

In block <NUM>, server <NUM> analyzes expected resource usage data per location and time and identifies resources likely to be available for other gateways (e.g., analyzing expected usage resource data for either or both of satellite or cellular gateways <NUM>, <NUM>) subject to regulatory constraints. This includes receiving input from ITU regulation data <NUM>, host nation agreement data <NUM>, and historical resource availability data <NUM>.

In block <NUM> which follows block <NUM>, server <NUM> determines resource availability per location and time (e.g., for a plurality of terminals <NUM>).

And in block <NUM> which follows, server <NUM> distributes resource availability data per location and time-e.g., to all participating satellite and/or cellular gateways <NUM>, <NUM>. Block <NUM> includes transmitting via any suitable mode this resource availability data (e.g., via cellular mode, via satellite mode, or the like).

Turning now to <FIG>, a process <NUM> is shown which may be executed between the satellite gateway <NUM> and the cellular gateway <NUM> via the management plane <NUM>, control plane <NUM>, and a data plane. Process <NUM> may facilitate further resource sharing. In process <NUM>, the satellite gateway <NUM> is illustrated as requesting resources (e.g., one or more frequencies at a predetermined time or for a predetermined duration) from cellular gateway <NUM>; however, it should be appreciated that in other examples, cellular gateway <NUM> could request resources from satellite gateway <NUM> instead.

Block <NUM> includes satellite gateway <NUM> determining its own resource availability per location and time. Input to this block includes data from block <NUM> (of <FIG>).

Block <NUM> which follows includes satellite gateway <NUM> determining a need for resources at a specific location and time, wherein gateway <NUM> may be able to acquire such resources from cellular gateway <NUM>.

In block <NUM> which follows, satellite gateway <NUM> sends a request cellular gateway <NUM> for 'buying' resources therefrom. The terms 'buy' and ' sell' refer to the satellite and cellular gateways <NUM>, <NUM> using a secure transaction technique to exchange information regarding resources-e.g., a blockchain or other suitable technology.

Blocks <NUM> and <NUM> may occur at the cellular gateway <NUM>. In block <NUM>, the cellular gateway <NUM> may analyze the request from the satellite gateway <NUM> and confirm a 'sale' of resources for a specific location and time.

In block <NUM> which follows, the cellular gateway <NUM> may send a confirmation for 'selling' resources to satellite gateway <NUM>.

In block <NUM> which follows, satellite gateway <NUM> re-determines its resources based on the acquisition from the cellular gateway <NUM>, and in block <NUM>, the satellite gateway <NUM> stores updated resource usage data per location and time in memory.

And in block <NUM> which follows, satellite gateway <NUM> updates (in computer <NUM>) its resource usage data per location and time. Of course, were the process <NUM> illustrated with respect to the cellular gateway <NUM> being the recipient, the cellular gateway <NUM> would update this information instead.

Turning to <FIG>, a schematic diagram of a process <NUM> for operating control plane <NUM> of satellite and cellular gateways <NUM>, <NUM> is illustrated. As process <NUM> may be similar for either gateway, process <NUM> will be described with respect to only one (satellite gateway <NUM>).

The process may begin by traffic trend data <NUM> and service plan data <NUM> being utilized in block <NUM>. In block <NUM>, control plane <NUM> of satellite gateway <NUM> may analyze current traffic trend data <NUM> with respect to service plan data <NUM> and identify usage change data per location and time.

Thereafter, in block <NUM>, satellite gateway <NUM> may determine and store incremental resource usage change data per location and time.

Following this, in block <NUM>, satellite gateway <NUM> may adjust resource usage plan data per location and time.

In block <NUM> which follows, satellite gateway <NUM> may determine resource usage data per location and time with a probability greater than a threshold.

In block <NUM>, satellite gateway <NUM> may send the determined resource usage data per location and time (of block <NUM>) to the server <NUM>.

And also following block <NUM>, satellite gateway <NUM> may collect resource usage data. At least some of this collected data may be used to update historical traffic data <NUM>.

Turning to <FIG>, a schematic diagram of a process <NUM> for operating a data plane of satellite and cellular gateways <NUM>, <NUM> is illustrated. As process <NUM> may be similar for either gateway, process <NUM> will be described with respect to only one (satellite gateway <NUM>).

The process may begin by current traffic data <NUM> and traffic trend data <NUM> being utilized in block <NUM>. In block <NUM>, the data plane of satellite gateway <NUM> may analyze current traffic data <NUM> with respect to traffic trend data <NUM> and identify usage change data per location and time.

In block <NUM> which follows, satellite gateway <NUM> may determine resource usage data per location and time.

Thereafter, in block <NUM>, satellite gateway <NUM> may send the determined resource usage data per location and time to the server <NUM>.

Turning now to <FIG>, a MAC (or data link) layer coordination is illustrated, wherein, at the MAC layer, resource sharing utilizes dynamic frequency, time, and power availability information to coordinate waveform specific multi-access schemes. Again, the server <NUM> can maintain a large multi-dimensional and geographic database that efficiently stores indexed data related to regulatory constraints, locations of satellite gateways <NUM>, satellites <NUM>-<NUM> and cellular nodes <NUM>, <NUM>, locations and trajectories of terminals <NUM> and/or satellites <NUM>-<NUM>, and the relationship between the terminals <NUM> and the gateways <NUM> and nodes <NUM>, <NUM>. For example, <FIG> illustrates server <NUM>, resource availability data <NUM> (per location, time, and system), and information regarding signal direction, signal frequency, and signal power all being inputs to a resource pool <NUM> of satellite gateway <NUM> and/or cellular gateway <NUM>. The pool <NUM> can comprise management plane baseline data <NUM>, mid-term adjustment data <NUM>, and frame-level refinement data <NUM>-e.g., all of which may be input to respective MAC layer <NUM> of gateway <NUM>, <NUM>. As shown, the MAC layer <NUM> (of either gateway <NUM>, <NUM>) may comprise a scheduler, and the scheduler thus may receive data from multiple traffic queues (e.g., such as queues <NUM>, <NUM>, <NUM>) and efficiently output <NUM> a transmission that comprises data from the queues <NUM>, <NUM>, <NUM> according to a predetermined schedule.

Now turning to <FIG>, a process <NUM> is shown illustrating how orchestrator server <NUM> may control terminal <NUM> to switch selectively back-and-forth between a first long-range wireless communication (LRWC) mode and a second LRWC mode. For purposes of illustration only (in <FIG>), the first LRWC mode will be described as a cellular mode, and the second LRWC mode will be described as a satellite mode; however, it should be appreciated that (in other examples) the first LRWC mode could be a satellite or other mode, and the second LRWC mode could be a cellular or other mode. Further, process <NUM> could utilize a third LRWC mode, a fourth LRWC, etc., as well. The process <NUM> illustrates some of the instructions which may be stored in memory <NUM> and which may be executable by processor <NUM> (of the server <NUM>).

Process <NUM> begins with block <NUM> wherein server <NUM> instructs terminal <NUM> to transmit or receive data via the first LRWC (cellular) mode via a first carrier frequency-e.g., having an established cellular link between it and gNB node <NUM> (of course, in other examples, the cellular link could be between terminal <NUM> and ng-eNB node <NUM> instead). In the cellular mode, the terminal <NUM> may control antenna <NUM> to be in an omnidirectional mode (as described above). Further, the cellular mode values of at least some of the dynamic parameters discussed above may be used.

In block <NUM>, server <NUM> may determine whether to instruct terminal <NUM> (e.g., via a cellular link) to transmit or receive data via a second LRWC (satellite) mode using the same first carrier frequency. For example, based on increased network traffic over the first LRWC and decreased network traffic over the second LRWC, server <NUM> may consider terminal <NUM> to be a candidate for switching between the first and second LRWC modes. If so, process <NUM> proceeds to block <NUM>; else, process <NUM> loops back and repeats block <NUM>.

In block <NUM>, server <NUM> may evaluate one or more conditions regarding terminal <NUM>. For example, server <NUM> may determine whether the radio frequency interference (RFI) is suitable for such a radio link connection (e.g., suitable for terminal <NUM> to communicate via the requested satellite mode). According to one example, the interference may be suitable for such communication provided that-from the point of view of terminal <NUM>-a subtended angle between satellite <NUM> and the gNB node <NUM> is greater than or equal to a threshold alignment (THRALIGN). If the RFI is not suitable for switching to the satellite mode, then process <NUM> proceeds to block <NUM>; else, if the RFI is suitable for switching to the satellite mode, then process <NUM> proceeds to block <NUM>. Server <NUM> is suitably situated to receive information regarding the positions of satellites <NUM>, terminal <NUM>, nearby cellular nodes <NUM>, <NUM>, etc. Accordingly, using Euclidean geometry, server <NUM> may calculate such a subtended angle and determine whether the angle is less than the predetermined threshold alignment (THRALIGN).

<FIG> is a diagram to illustrate determining the threshold alignment (THRALIGN). More particularly, <FIG> illustrates terminal <NUM>, satellite <NUM>, and gNB node <NUM>. Further, the figure illustrates a first axis A (extending between terminal <NUM> and satellite <NUM>), a second axis B (extending between terminal <NUM> and gNB node <NUM>), a third axis C (extending between terminal <NUM> and satellite <NUM>), and a fourth axis D (extending between gNB node <NUM> and a major axis of a radio link transmission (e.g., a major axis of a lobe (not shown))). Terminal <NUM> may determine an angle θT between the axes B, C (e.g., using received signal strength indicator (RSSI) data, time-of-flight (TOF) data, angle-of-arrival (AoA) data, and/or other techniques including those discussed above (e.g., a two-line element (TLE) technique)). If the value of angle θT is less than THRALIGN, then computer <NUM> may determine to proceed to block <NUM>. Else, computer <NUM> may determine to proceed to block <NUM>.

According to one non-limiting example, threshold alignment (THRALIGN) is <NUM> degrees (°). Before discussing blocks <NUM> and <NUM>, an exemplary derivation of the interference (RFI) is disclosed. Empirically, the RFI is suitable for dynamically switching between the first and second LWRC modes when the angle θT is less than the threshold alignment (THRALIGN). For example, the value of the threshold alignment (THRALIGN) may be based on factors such as receiving antenna gain, transmitting antenna gain, and interference, as discussed below and shown in Equation (<NUM>). <MAT>
wherein RFI is interference, PT is transmit power of a radio link, GR(θR) is a receiving antenna gain, GT(θT) is a transmitting antenna gain, and SFL is a free space loss. GT() is a function of θT, wherein θT is an angle between an interfering antenna and a receiving antenna boresight. And GR() is a function of θR, wherein θR is a direction of an interfering link with respect to terminal <NUM>.

Assuming, e.g., server <NUM> is determining whether the threshold alignment of terminal <NUM> is suitable for transmitting data to satellite <NUM>, PT may be the transmit power of a radio link from terminal <NUM> to satellite <NUM> along axis C. GT(θT) may be a transmitting antenna gain of terminal <NUM>, wherein θT is the angular measure between an interfering antenna (of gNB node <NUM>) and the receiving antenna boresight of satellite <NUM> (e.g., along axis C).

Returning to <FIG>, recall the process <NUM> proceeds to block <NUM> when angle θT is less than the threshold alignment (THRALIGN); i.e., server <NUM> determines the RFI to be too excessive. In block <NUM>, server <NUM> may determine whether another satellite is available (e.g., determining that satellite <NUM> may be used). If not, server <NUM> proceeds to block <NUM>. If another satellite is available, then process <NUM> may loop back and repeat block <NUM> (e.g., determining an angle between axis A and axis B. Block <NUM> is optional and may not be included in all examples.

In block <NUM>, if no satellite is available (at an angle greater than or equal to the threshold alignment (THRALIGN) with respect to gNB <NUM>), then server <NUM> determines a state of "no satellite is available. " Thereafter, the process may loop back to block <NUM>-permitting terminal <NUM> to continue to transmit or receive via the cellular mode.

Returning to block <NUM>-which may follow block <NUM>, server <NUM> may instruct terminal <NUM> to change LRWC modes-e.g., from the cellular mode to the satellite mode. In one example, the instruction also may specify a satellite selection (e.g., satellite <NUM>). The instructions further may comprise server <NUM> commanding terminal <NUM> to control a directionality of its antenna <NUM>-e.g., beamforming in the direction (along a boresight of) the satellite <NUM> (e.g., along axis C). Block <NUM> further may comprise server <NUM> instructing terminal <NUM> to use a different set of dynamic parameters. Accordingly, terminal <NUM> may receive these dynamic parameters and update its SDR, thereby permitting the terminal <NUM> to operate in the second LRWC mode (satellite) while using the same frequency used in the first LRWC mode.

Following block <NUM>, the process <NUM> may proceed to block <NUM> (shown on <FIG>). In block <NUM>, terminal <NUM> may transmit or receive data using the first carrier frequency, but via a satellite link.

Block <NUM> follows. In block <NUM>, server <NUM> may determine whether to instruct terminal <NUM> to again transmit or receive data via the first LWRC mode. In some cases, this determination again may include terminal <NUM> using the first carrier frequency. If server <NUM> determines not to so instruct terminal <NUM>, then process <NUM> may loop back and continue to execute block <NUM>. However, if server <NUM> so determines, then process <NUM> may proceed to block <NUM>.

In block <NUM>, server <NUM> may determine whether the radio frequency interference (RFI) is suitable for such a radio link connection (e.g., suitable for terminal <NUM> to communicate via the requested cellular mode). In general, block <NUM> may be identical or similar to the instructions of block <NUM>; therefore, this will not be described in detail here. If the RFI is not suitable for switching to the cellular mode (and using the same first carrier frequency), then process <NUM> may proceed to block <NUM>; else, if the RFI is suitable for switching to the cellular mode (and using the same first carrier frequency), then process <NUM> proceeds to block <NUM>.

In block <NUM>, the computer <NUM> instructs terminal <NUM> to change to the first LRWC mode. For example, as before, this may include identifying a satellite, commanding the terminal <NUM> to control antenna directionality, providing terminal <NUM> dynamic parameters, and the like. Accordingly, terminal <NUM> may revert antenna <NUM> to the omnidirectional mode, etc. Thereafter, server <NUM> again proceeds to block <NUM> (<FIG>), and terminal <NUM> may communicate via the cellular mode.

In block <NUM> which may follow block <NUM>, server <NUM> may evaluate for another cellular node (e.g., another gNB node <NUM> or a ng-eNB node <NUM>). If a suitable cellular node is discovered, then process <NUM> may proceed to block <NUM>, as described above. If not, the process may proceed to block <NUM>.

In block <NUM>, server <NUM> may determine that a state of terminal <NUM> is "no available cellular node. " Thereafter, process <NUM> may loop back to and repeat block <NUM>.

It should be appreciated that regarding process <NUM>-in some examples terminal <NUM> may be fixed (e.g., to a building or other structure); however, this is not required (e.g., terminal <NUM> may be mobile). Further, it should be appreciated that in some examples, satellites <NUM>, <NUM> may be relatively fixed-with respect to terminal <NUM>-in the sky as well (e.g., a GEO satellite and a fixed terminal <NUM>). However, in other examples, satellites <NUM> and/or <NUM> may be otherwise GSO or NGSO. In these latter instances, (from the point of view of the terminal <NUM>) a subtended angle between the satellite <NUM>, <NUM> and cellular node <NUM> (respectively) sometimes may be less than the threshold alignment (THRALIGN) and sometimes may be greater than or equal to the threshold alignment (THRALIGN), as the satellites <NUM>, <NUM> could be moving (e.g., with respect to earth). A similar set of circumstances can exist with a fixed position satellite and a moving terminal-or with both a moving satellite and a moving terminal.

According to one aspect of process <NUM>, the process may utilize satellite communication latency. For example, there is a significant difference in propagation delay (satellite communication latency)-e.g., between satellite communication and terrestrial (e.g., cellular) communication (e.g., a time between scheduling and transmission toward satellite <NUM>, <NUM> from satellite gateway <NUM> and a time the signal is received at terminal <NUM> may be approximately <NUM> milliseconds). In some examples, server <NUM> can communicate this satellite communication latency to a cellular node (e.g., ng-eNB <NUM> and/or gNB <NUM>). Further, concurrent with (or even after) transmitting a satellite uplink from gateway <NUM>, gateway <NUM> may inform cellular nodes <NUM>, <NUM> (via a cellular link) of forthcoming satellite link data. Forthcoming satellite link data, as used herein, refers to data pertaining to satellite link parameters that is communicated via a cellular link; examples of forthcoming satellite link data include: satellite link waveform data, satellite link power level data (e.g., expected or estimated by calculation), and satellite link timing data (time of arrival, duration, etc.). Accordingly, the respective cellular node <NUM>, <NUM> may communicate this with terminal <NUM>-enabling it to switch from the cellular mode to the satellite mode at a predetermined, appropriate timing.

Thus, in consideration of the exemplary propagation delays discussed above, the delay difference between satellite system and terrestrial systems permits server <NUM> to utilize the cellular AN <NUM> (e.g., one of nodes <NUM>, <NUM>) to communicate with and thereby prepare terminal <NUM> to switch between the first and second LRWC modes-e.g., even if the message sent via cellular mode is transmitted after the data being transmitted via satellite mode.

The description above refers to an exemplary terminal (e.g., <NUM>), wherein terminal <NUM> is representative of potentially countless numbers of similar or identical such terminals. Further, other terminals may be configured differently from terminal <NUM> and may be utilizing either a cellular link or a satellite link. Accordingly, it should be appreciated that numerous satellite links and numerous cellular links may be occurring concurrently. As used herein, satellite traffic refers to a quantity of data being communicated by a satellite link over a predefined quantity of time, and as used herein, cellular traffic refers to a quantity of data being communicated via one or more cellular nodes over a predefined quantity of time. Using the telecommunication system <NUM> described above, satellite and cellular traffic can be balanced to improve an overall communication efficiency of the system (e.g., when satellite traffic is low and cellular traffic is high, orchestrator server <NUM> may shift some of the cellular links of terminals <NUM> to satellite links thereby improving overall throughput and efficiency; or e.g., when satellite traffic is high and cellular traffic is low, orchestrator server <NUM> may shift some of the satellite links of terminals <NUM> to cellular links similarly improving overall throughput and efficiency).

Thus, there has been described an orchestrator server that can help facilitate the multi-mode functionality of a terminal that can switch between a first long-range wireless communication (LRWC) mode and a second LRWC mode.

Other embodiments of system <NUM> also exist. For example, <FIG> illustrates another embodiment of the telecommunication system <NUM> described above, wherein expected (e.g., estimated) interference at terminal <NUM> and/or at cellular node (e.g., <NUM>, <NUM>) may be used by server <NUM> to improve performance in a terrestrial cell. For example, <FIG> illustrates an example of terminal <NUM> being located within a satellite coverage area <NUM> of a beam <NUM> (the satellite beam comprising a frequency f<NUM>) and also located within a cellular coverage area <NUM> (the cellular node <NUM> utilizing a frequency f<NUM>). <FIG> further illustrates a neighboring satellite beam <NUM> (the satellite beam comprising the frequency f<NUM>) projecting a satellite coverage area <NUM>. As the cellular coverage area <NUM> may be near a fringe region <NUM> of coverage area <NUM> and near a fringe region <NUM> of coverage area <NUM>-and as beam <NUM> and node <NUM> may communicate using the same frequency (f<NUM>), the node <NUM> and/or the terminal <NUM> may experience higher than typical interference. According to one example, the information carried by beam <NUM> can be used by cellular node <NUM> to improve the performance at the terminal <NUM>. For example, server <NUM> can instruct the cellular node <NUM> to modify its transmission waveform so that when the cellular transmission is added to the expected interference at terminal <NUM>, this cellular transmission will cancel the expected interference.

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 Hughes proprietary operating and software systems, 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, a vehicle computer, 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.

The processor is 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 circuits ASICs), one or more digital signal processors (DSPs), one or more customer integrated circuits, etc. The processor may be programmed to process the sensor data. Processing the data may include processing inroute and outroute communications between a gateway computer and a plurality of terminals.

The memory (or data storage device) is implemented via circuits, chips or other electronic components and can include one or more of read only memory (ROM), random access memory (RAM), flash memory, electrically programmable memory (EPROM), electrically programmable and erasable memory (EEPROM), embedded MultiMediaCard (eMMC), a hard drive, or any volatile or non-volatile media etc. The memory may store data collected from sensors.

Claim 1:
A system (<NUM>), comprising:
an orchestrator server (<NUM>), comprising:
a computer (<NUM>) communicatively coupled to a satellite gateway (<NUM>) and a cellular access network (<NUM>), the computer (<NUM>) comprising:
a processor (<NUM>); and
memory (<NUM>), coupled to the processor (<NUM>), storing instructions executable by the processor (<NUM>), the processor (<NUM>) configured to:
instruct a first terminal (<NUM>) having a software stack (<NUM>) that enables the terminal (<NUM>) to operate as a software defined radio (SDR) to communicate wirelessly via a carrier frequency using a first long-range wireless communication (LRWC) mode, wherein in the first LRWC mode the first terminal uses a first set of dynamic parameters of layers in the software stack;
determine that, relative to the first terminal (<NUM>), a subtended angle between a satellite (<NUM>, <NUM>) and a cellular node (<NUM>) is less than an alignment threshold; and
based on the determination, transmit a command to the first terminal (<NUM>) to communicate wirelessly via the carrier frequency using a second LRWC mode, wherein the first LRWC mode is different to the second LRWC mode and wherein the first terminal uses a second set of dynamic parameters of layers in the software stack in the second LRWC mode, wherein the first set comprises at least one dynamic parameter that is different from each dynamic parameter in the second set.