Space communication protocol

Abstract

The satellite comprises a communication link interface, at least one processor, and at least one memory. The at least one processor and the at least one memory are configured to support a plurality of tenant applications in a multi-tenant cloud computing environment, and two or more of the plurality of tenant applications establish independent communication link channels with a ground station using the communication link interface.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 389,318, filed on July 14, 2022, the entire content of which is incorporated herein by reference.

[0002] This disclosure generally relates to distributed processing systems, and more particularly to communication systems and protocols.

Summary of the Invention

[0003] This disclosure provides, among other things, a space communication protocol for enabling multi - tenant satellite systems. The protocol may be applied to communication from a ground station to a satellite and / or from a satellite to a satellite. This disclosure provides many advantages depending on the particular configuration. These and other advantages will become apparent from the disclosure contained herein.

[0004] The phrases “at least one”, “one or more”, and “and / or” are open - ended expressions that operate both conjunctively and disjunctively. For example, each of the expressions “at least one of A, B, and C”, “at least one of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B, or C” and “A, B, and / or C” means only A, only B, only C, both AB, both AC, both BC, or all of ABC.

[0005] The term “an” entity or “a” entity refers to one or more of that entity. Thus, the terms “a” (or “an”), “one or more” and “at least one” may be used interchangeably herein. It should also be noted that the terms “comprising”, “including”, and “having” may be used interchangeably.

[0006] The term "application containerization" refers to an operating system-level virtualization method for deploying and running distributed or virtualized applications (e.g., containerized or virtual machine-based applications) without starting an entire virtual machine for each application. Multiple independent applications or services are run on a single host and access the same operating system kernel.

[0007] The term "automatically" and its variations refer to any process or operation that occurs without significant human input when the process or operation is executed. However, a process or operation may be considered automatic even if the execution of the process or operation uses significant or insignificant human input, provided that the input is received prior to the execution of the process or operation. Human input is considered significant if such input affects how the process or operation is executed. Human input that merely consents to the execution of a process or operation is not considered "significant".

[0008] The term "computer-readable medium" refers to any tangible storage medium and / or transmission medium involved in providing instructions to a processor for execution. Such media can take many forms including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, NVRAM, or magnetic disks and optical disks. Volatile media includes dynamic memory such as main memory. Common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, or any other magnetic medium, magneto-optical media, CD-ROM, any other optical media, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, and EPROM, FLASH-EPROM, solid media such as memory cards, any other memory chip or cartridge, carrier waves described hereinafter, or any other medium readable by a computer. Digital files attached to electronic mail, or other self-contained information archives or sets of archives are considered distribution media equivalent to tangible storage media. When a computer-readable medium is configured as a database, it should be understood that the database can be of any type, such as relational, hierarchical, object-oriented, etc. Accordingly, the present disclosure is considered to include tangible storage media or distribution media in which software implementations of the present disclosure are stored, as well as equivalents and successor media recognized in the prior art.

[0009] The term "cluster" refers to a group of multiple worker nodes that deploy, execute, and manage containerized or VM-based applications, and a master node that controls and monitors the worker nodes. A cluster may have internal and / or external network addresses (e.g., DNS names or IP addresses) to enable communication between containers or services and / or with other internal or external network nodes.

[0010] The term "container" refers to a form of operating system virtualization that separates processes and controls the amount of central processing unit (CPU), memory, and disk that those processes can access, enabling multiple applications to share an operating system. Like virtual machines, containers share common underlying hardware, but unlike virtual machines, containers share the underlying virtualized operating system kernel and do not run separate operating system instances.

[0011] The terms "determine", "calculate", and "compute" and their variants are used interchangeably and include any type of methodology, process, mathematical operation, or technique.

[0012] The term "deploy" refers to the creation, status, and execution control of containerized or VM-based applications. It can specify the number of replicas of pods to be run on a cluster. When a pod fails, the deployment generates a new pod.

[0013] The term "domain" refers to a set of objects that define the scope of all infrastructure under management within a single context. The infrastructure can be physical or virtual and can be hosted on-premises or in a public cloud. Domains are mutually exclusive, and there is no overlap of infrastructure within any two domains.

[0014] The terms "microservices" or "microservices architecture (MSA)" may be used to refer to an architectural style in which an application is deployed as small services with messaging and is bound to a context. The services are developed autonomously using any suitable programming language, are not constrained by software or hardware environments, and are deployed independently in a distributed system. Autonomous satellites, and the platforms used to build and manage them, utilize microservices or MSA applications. A satellite may include three microservice-based distributed modules: a bus / core, a mission / payload service, and an edge. These three microservice-based distributed modules are connected by an internal network and may use messaging / APIs for communication. In cloud-based development of a satellite, a replica of the satellite in orbit is maintained as a digital twin, components and processes are implemented as services within the cloud, and remote communication is performed using a protocol that does not rely on technologies such as HTTP for the user and supplier ecosystem in development.

[0015] The term "module" refers to any known or later-developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software that can perform the functionality associated with its elements. Also, although the present disclosure has been described with respect to exemplary embodiments, it should be understood that the individual aspects of the present disclosure may be claimed separately.

[0016] The term "namespace" refers to a set of symbols (names) used to identify and reference various types of objects. Kubernetes has three main namespaces: default, kube-system (used for Kubernetes components), and kube-public (used for public resources). Namespaces are intended for use in environments where many users span multiple teams and projects. At a higher level, the extension to namespaces enables multiple virtual clusters (or namespaces) supported by a common set of physical (Kubernetes) clusters.

[0017] The term "pod" refers to a group of containers that share the same compute resources and the same network.

[0018] The term "tenant" refers to an organizational construct or logical grouping used to represent an explicit set of resources within a domain (e.g., physical infrastructure such as central processing units (CPUs), graphics processing units (GPUs), memory, storage, network, cloud clusters, people, etc.). Tenants "exist" within the infrastructure managed by the service provider. By default, individual tenants neither overlap nor share. That is, each tenant may be separated data-wise, physically, and at runtime from other tenants by defining a resource scope dedicated to each tenant. Put another way, the first tenant may access a different set of resources, resource capabilities, and / or resource capacities than the second tenant. The service provider assigns worker nodes to tenants, and tenant administrators form clusters from the worker nodes.

[0019] The term "virtual machine" refers to a server abstracted from underlying computer hardware so that a physical server can execute multiple virtual machines or a single virtual machine spanning multiple servers. Each virtual machine typically runs its own operating system instance, enables separation of each application within its own virtual machine, and reduces the possibility that applications running on common underlying physical hardware will affect each other.

[0020] The term "communication link" refers to a radio frequency communication link, an optical communication link, and / or any communication medium between one or more satellites, and also refers to any communication link medium between satellite and satellite, and / or between a satellite and a ground station. Communication between satellites may be referred to herein as a sidelink, and / or an "inter-satellite communication link", and / or an ISCL. Communication from a ground station to a satellite may be referred to herein as uplink communication. Communication from a satellite to a ground station may be referred to herein as downlink communication. The term "communication link" may also refer to two or more "communication links" between satellites, and / or there may be two or more "communication links" between a satellite and a ground station.

[0021] The above is a simplified overview of the present disclosure to provide an understanding of some aspects of the present disclosure. This overview is neither an extensive nor an exhaustive overview of the present disclosure and its various embodiments. It is not intended to identify basic or important elements of the present disclosure or to clarify the scope of the present disclosure, but rather to present selected concepts of the present disclosure in a simplified form as an introduction to the more detailed description below. As will be understood, other embodiments of the present disclosure may utilize one or more of the features described above or detailed below, alone or in combination.

[0022] The accompanying drawings are incorporated herein to illustrate several examples of the present disclosure and form a part hereof. These drawings, together with the description, explain the principles of the present disclosure. The drawings merely show preferred and alternative examples of how the present disclosure may be generated and used, and should not be construed as limiting the present disclosure to only the illustrated and described examples. Further features and advantages will become apparent from the following more detailed description of various aspects, embodiments, and configurations of the present disclosure, as shown by the drawings referred to below.

[0023] Further details of the present disclosure are set forth in the following attached documents, each of which is incorporated herein by reference.

Brief Description of the Drawings

[0024]

Figure 1A

Figure 1B

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0025] The present disclosure relates to a satellite or system that may include a satellite and a ground station. In any case, the satellite and the ground station according to the embodiments of the present disclosure enable a plurality of different separate users to access the same resources (e.g., payload) of the satellite and execute different missions in a fast, reliable, and secure manner.

[0026] Further details of the present disclosure are set forth in the following attached documents, each of which is incorporated herein by reference.

[0027] Exemplary systems and methods are described in connection with satellites that deploy resources in a particular manner. However, to avoid unnecessarily obscuring the present disclosure, many known components and devices have been omitted from the foregoing description. This omission should not be construed as limiting the scope of the claimed disclosure. Specific details are set forth to provide an understanding of the present disclosure. However, it is to be understood that the present disclosure may be practiced in various ways beyond the specific details described herein.

[0028] Furthermore, in the embodiments shown herein, while various components of the system are shown collocated, certain components of the system may be remotely located in remote portions of a distributed network such as a LAN and / or the Internet, or within a dedicated system. Thus, it is to be understood that the components of the system may be combined in one or more devices such as a server, or collocated at particular nodes of a distributed network such as an analog and / or digital telecommunications network, a packet switched network, or a circuit switched network. From the foregoing description, and for reasons of computational efficiency, it will be understood that the components of the system may be located at any position within the distributed network of components without affecting the operation of the system. For example, the various components may be located in a switch such as a PBX or media server, a gateway, one or more communication devices, the homes of one or more users, or some combination thereof. Similarly, one or more functional portions of the system may be distributed between a computing device associated with a telecommunications device.

[0029] Furthermore, it should be understood that the various links connecting the elements may be wired or wireless links, or any combination thereof, or any other known or later-developed element capable of supplying and / or communicating data between the connected elements. These wired or wireless links may be secure links and may be able to communicate encrypted information. The transmission medium used as the link may be any carrier suitable for electrical signals, including, for example, coaxial cables, copper wires, and optical fibers, and may take the form of sound waves or light waves such as those generated during radio waves or infrared data communication.

[0030] Also, although the flowcharts have been discussed and illustrated in relation to a particular order of events, it should be understood that changes, additions, and omissions to this order may occur without substantially affecting the operations of the present disclosure.

[0031] Many variations and modifications of the present disclosure may be used. It would be possible to provide some features of the present disclosure without providing other features.

[0032] In yet another embodiment, the systems and methods of the present disclosure may be implemented in conjunction with special-purpose computers, programmed microprocessors or microcontrollers and peripheral integrated circuit elements, ASICs or other integrated circuits, digital signal processors, hardwired electronic circuits or logic circuits such as discrete element circuits, programmable logic devices or gate arrays such as PLDs, PLAs, FPGAs, PALs, special-purpose computers, any equivalent means, and the like. In general, any device or means capable of implementing the methods shown herein may be used to implement the various aspects of the present disclosure. Exemplary hardware that may be used in the present disclosure includes computers, handheld devices, telephones (e.g., cellular, Internet-enabled, digital, analog, hybrid, etc.), and other hardware known in the art. These devices may include processors (e.g., single or multiple microprocessors), memory, non-volatile storage, input devices, and output devices. Additionally, alternative software implementations including, but not limited to, distributed processing or component / object distributed processing, parallel processing, or virtual machine processing may be constructed to implement the methods described herein.

[0033] In yet another embodiment, the disclosed methods may be readily implemented with software using an object or object-oriented software development environment that provides portable source code that can be used on various computer or workstation platforms. Alternatively, the disclosed systems may be implemented partially or fully in hardware using standard logic circuits or VLSI designs. Whether software or hardware is used to implement the systems according to the present disclosure depends on system speed and / or efficiency requirements, particular functions, and the particular software, hardware system, microprocessor, microcomputer system utilized.

[0034] In yet another embodiment, the disclosed method may be partially implemented in software stored on a memory medium and executable on a general-purpose computer, a special-purpose computer, a microprocessor, etc., programmed by the cooperation of a controller and a memory. In such a case, the systems and methods of the present disclosure may be implemented as a program incorporated into a personal computer, such as an applet, JAVA (registered trademark), or CGI script, as a resource existing on a server or computer workstation, as a routine incorporated into a dedicated measurement system, system component, etc. The system may also be implemented by physically incorporating the system and / or method into a software and / or hardware system.

[0035] The present disclosure describes the components and functions implemented in embodiments with reference to specific standards and protocols, but the present disclosure is not limited to such standards and protocols. There are other similar standards and protocols not mentioned herein, which are considered to be included in the present disclosure. Further, the standards and protocols mentioned herein, as well as other similar standards and protocols not mentioned herein, are periodically replaced by equivalent ones having essentially the same function, which are faster or more effective. Such replacement standards and protocols having the same function are considered to be equivalents included in the present disclosure.

[0036] This disclosure includes components, methods, processes, systems, and / or devices substantially as illustrated and described herein, including various embodiments, configurations, and aspects, as well as various sub - combinations and subsets thereof. Those skilled in the art will understand the manufacturing and usage methods of this disclosure after understanding this disclosure. This disclosure includes, in various embodiments, configurations, and aspects, providing devices and processes in the absence of items not shown and / or described herein, or in various embodiments, configurations, or aspects of this specification, which may include, for example, items that may have been used in previous devices or processes to improve performance, achieve ease of use, and / or reduce implementation costs even in the absence of such items.

[0037] The foregoing discussion of the disclosure has been presented for purposes of illustration and description. It is not intended to limit the disclosure to the forms disclosed herein. For example, in the above - detailed description, various features of the disclosure are grouped together in one or more embodiments, configurations, or aspects for the purpose of streamlining the disclosure. The features of an embodiment, configuration, or aspect of the disclosure may be combined with alternative embodiments, configurations, or aspects other than those described above. This method of disclosure should not be construed as intending that the claimed disclosure requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, the inventive aspects lie in less than all of the features of a single foregoing disclosed embodiment, configuration, or aspect. Accordingly, the following claims are incorporated into the forms of this invention herein, and each claim stands on its own as a separate preferred embodiment of this disclosure.

[0038] Furthermore, the description of the present disclosure includes descriptions of one or more embodiments, configurations, or aspects, as well as specific variations and modifications. However, other variations, combinations, and modifications may be within the scope of the present disclosure, such as within the skill and knowledge of those skilled in the art after understanding the present disclosure. Whether or not such alternative, interchangeable, and / or equivalent structures, functions, scopes, or steps are disclosed herein, and without intending to publicly dedicate patentable subject matter, it is intended to obtain the right to alternative embodiments, configurations, or aspects that include alternative, interchangeable, and / or equivalent structures, functions, scopes, or steps within the allowable scope of what is claimed.

[0039] Generally, exemplary embodiments relate to the specifications of the flow of telecommands (TC), telemetry (TM), and telemetry data (TD) between a ground station (GS) and a satellite, as well as between different satellites and between different ground stations. Exemplary embodiments cover a wide range of currently implemented use cases and use cases envisioned for next-generation space technology. The TC / TM / TD formats and call flows described herein are designed to be mission-agnostic and wireless-technology-agnostic and may be adapted to LEO, MEO, GEO, EO (Earth Observation), and COM (Communication), and generally, any category of satellite and / or spacecraft. The command format and command scheduling cover commands from a ground station to a satellite and commands between satellites via an inter-satellite communication link (ISCL).

[0040] When designing the protocol and frame format for TC / TM messages, the following non-limiting and exemplary use cases are envisioned. It should be noted that the exemplary use cases specified in this section do not necessarily cover all use cases defined in other sections of this document. 1. One entity launches one satellite and executes a mission / application that sends multiple commands. 2. One entity launches one satellite and executes multiple missions / applications that send multiple mission-specific commands. 3. One entity launches multiple satellites, executes various applications / missions on each satellite, and sends multiple commands to applications / missions that are executed individually on multiple satellites. 4. One entity that owns multiple satellites (Satellites 1, 2, 3, 4, 5) sends a single telecommand to all of its owned satellites. This is sometimes called a telecommand broadcast, and this broadcast is not at the radio link level but rather at the telecommand center application layer. At the radio link level, commands still address one satellite at a time. 5. One entity that owns multiple satellites (1, 2, 3, 4, 5) sends a single telecommand to some of its owned satellites (1, 2, 3). This is sometimes called a telecommand multicast, and this multicast is not at the radio link level but rather at the telecommand center application layer. At the radio link level, commands still address one satellite at a time. 6. A single satellite carries multiple payloads / missions, and the payloads / missions are shared by different / multiple users. Multiple users or entities send multiple commands to each payload / mission application that is executed on the single satellite. In this use case, mission / payload users are given access rights to schedule their own commands in a private and secure manner for their payloads / missions. 7. Multiple satellites carry multiple payloads / missions, and the payloads / missions are shared by different / multiple users / entities.Multiple users or entities send multiple commands to each payload / mission application running on a pool of satellites. In this use case, mission / payload users are given access rights to schedule their own commands in a private and secure manner, either in broadcast mode or multicast mode, for each payload / mission. 8. As shown in Figure 3, telecommands transmitted from satellite to satellite via any inter-satellite communication link (ISCL) communication in space without going through the GS / terrestrial entity. The inter-satellite "communication link" may form a network of neighboring satellites for transmitting and receiving TC, TM, and / or TD messages.

[0041] Exemplary embodiments of the present disclosure provide at least the following features and advantages. 1. Support for end-to-end application layer communication interfaces between the user experience UX / user interface UI (UX / UI) and the mission flight command & control (MFCC), between the payload command control (PCC) and the GS, between the GS and the satellite, and between satellites (inter-satellite communication). 2. Retention of a simplified lightweight data structure. 3. Support for multi-tenant applications. 4. End-to-end security in the application layer. 5. QoS in the telecommand and telemetry, unicast, multicast, and broadcast application layers. 6. Inter-satellite sidelink messaging that enables neighboring-aware satellite networking in space. 7. Satellites and ground stations perform internetworking and roaming via the MFCC interface, exchange TC / TM, and coordinate satellites across the ground station network and ISCL. 8. Emergency transmission using the ISCL / sidelink signal. 9. Limited / emergency access to GS transit time and band allocation for emergency communications (similar to mobile phones with emergency call access via any network). 10. Multicast and broadcast functions between GS and satellites, and between satellites. 11. Enable near-edge retransmission (RTX) of TC (e.g., the GS antenna notifies the MFCC of a TC transmission failure, the MFCC retransmits the TC, and the application layer receives ack-based RTX). 12. Standardization of TC and TM messages and data structures for OBC, ADCS, communication (wireless), EPS, and other sensors, payloads, subsystems, and satellite applications. 13. TC / TM support for multi-tenant applications running on one satellite - This architecture enables end-to-end independent and secure TC / TM exchange for each tenant. TC / TM can be split into flight command control and payload command control - Payload command control may have its own security enabled and be under payload / tenant management, and / or each payload owner may be granted secure TC / TM channel access rights to exchange TC / TM with a dedicated UI / UX plugin (where some restrictions and access level permissions for allowable TC / TM / TD, such as payload internal processing related to TC / TM / TD, may be defined). 14. Share resources between spacecraft (SVs) and support multi-tenant applications running across satellites / SVs (e.g., a mission running on SV1 offloads tasks to another SV - e.g., SV1 wishes to share computing resources with SV2 - in another example, SV1 is unable to successfully execute a critical mission at time T and orbital point location (OPL) 1 (the reasons for SV1's failure [environment, power, etc.] can be various), and sends a command / request to neighboring SV2 to continue the mission task by SV2). 15. When multi-tenancy and resource sharing are requirements, QoS and security automatically become requirements, which are addressed in the exemplary embodiments. QoS is based on the availability of "communication link" bandwidth by wireless link or optical link or other means, and the "communication link" bandwidth is limited and may be time-shared among multiple missions / payloads, so QoS at the TC / TM layer is useful - this function utilizes "satellite internetwork roaming" to perform load sharing and time sharing of GS and ISCL communication endpoint resources if permitted / applicable by other GSs and satellites within the space network. 16. Near-Neighbor Recognition Satellite Interconnectivity in Space - In certain applications where it may be necessary to cover the entire Earth / ground 24 hours a day, 365 days a year with 100% coverage, it can be useful to form a mesh network across all satellites and spacecraft in space. The TC / TM application layer interface is used for near-neighbor recognition of the satellite network. This architecture is achieved by enabling neighboring satellites to exchange secure communications and by interfacing with the GS database to obtain information. In addition, the GS client satellite (GSCS) TC can transmit the functions of each satellite, which include the following: i. The relative orbit time / distance of the GSCS to the current satellite in communication, ii. The downlink / uplink (DL / UL) data bandwidth permitted and available to the GSCS, iii. The GSCS ISCL function (number of ISCL antennas, "communication link" parameters, permitted and available ISCL data bandwidth), iv. Optionally, it may carry mission parameters and the processing / computing (sharable) functions of the GSCS neighboring satellites. The details of neighboring satellites that can be exchanged between satellites and stored in the database include the following: i. Neighboring satellite ID, ii. Current position and orbital parameters (satellites can calculate relative positioning, ISCL contact points, and transit times based on this information), iii. ISCL communication parameters, iv. Quality of the "communication link", available and permitted UL / DL data bandwidth via ISCL, v. Available and permitted data bandwidth from neighboring satellites to the GS "communication link" (both DL and UL), vi. Mission functions of neighboring satellites, vii. Processing / computing functions (sharable) of neighboring satellites, viii. Any other information that can support or facilitate each other's satellite missions may be exchanged and stored between satellites. In addition, this architecture may perform maintenance of the routing table of the neighboring satellite network. 17. MFCC Interface for Satellite Internet Roaming for TC / TM Exchange. The same operator may execute multiple MFCCs (for different sets of satellite / mission operations), and a cooperative method for exchanging TC / TM between satellites may be used. This interface may be a requirement based on how the space network is evolving. In one example, an SV of Network 1 identifies an anomaly and conveys the anomaly to the MFCC of the GS of Operator 1. That MFCC then conveys the anomaly to all other operators for taking emergency measures. There may be sharing of GS "communication link" resources across the satellite network. In some examples, the same TC (e.g., an emergency or critical TC) is scheduled across multiple GSs for redundancy and for guaranteed timely TC transmission to satellites within the network. In some cases, the TC triggers GS scans and neighboring satellite scans to identify new neighbors and / or new (not pre-configured) GSs for TC / TM exchanges of high urgency or mission importance. The commands / messages of the TC / TM interface may interact between MFCCs executed by two different satellite operators.

[0042] Figure 1A shows a system 100 that enables communication between a space segment including a satellite system 104 with one or more satellites 106 and a terrestrial or ground segment including a terrestrial system 108. The satellite 106 may have any suitable configuration such as a 1U satellite, 3U satellite, 6U satellite, etc. As shown, the satellite 106 may include various components typically associated with a satellite, such as payloads 1, 2, 3, a payload server PS, an edge server Edge, a power system (EPS) and a power distribution network (PDN), an on-board computer (OBC) communicable with them, an OBC connection hardware (HW) subsystem, and an attitude determination and control system (ADCS). The OBC may include its own applications, session management, and scheduler. The OBC may further include or communicate with one or more communication interfaces, such as software-defined radio (SDR) for S-band and / or X-band "communication links" via one or more antennas, and an interface enabling an inter-satellite communication link (ISCL) with other satellites 106. The S-band interface may be used to exchange TC and TM data between the satellite 106 and the ground station 110, and the X-band interface may be used to transmit mission data and payload data from the satellite 106 to the ground station 110. The ISCL may be a wireless link having any operating RF band, an optical link, or other means of a "communication link" used for communication between satellites 106. An example of such an ISCL is an optical inter-satellite link (OISL). As shown in FIG. 6, some satellites 106 may be constructed with an ISCL for inter-satellite communication and S-band and / or X-band for communication with ground stations. On the other hand, some satellites 106 may be constructed using only ISCLs for primary use in an inter-satellite communication network for relaying or routing TC, TM, and / or TD messages between satellites 106. Such types of satellites are sometimes referred to as relay-only satellites (ROS). In some cases, the satellite 106 includes multiple ISCLs to communicate with multiple satellites 106 simultaneously. FIGS. 5 and 6 show examples where satellites 106 communicate with each other via an ISCL.

[0043] In particular, the OBC further includes a specially programmed agent 112 that implements various advantageous functionalities described herein, including but not limited to enabling multi-tenant use of the resources of satellite 106. As shown, agent 112 includes or enables various modules, including but not limited to a module for neighboring satellite resource monitoring and resource sharing, a unicast-multicast-broadcast scheduler, a security module for encrypting and decrypting messages, a module for enabling ISCL using networking lists and routing tables, a database for storing a list of neighboring satellites and potential ground stations, a module for managing QoS, an ISCL tracker, a ground station and Earth link access tracker, and a module for encrypting and decrypting TC and TM. The OBC may include appropriate hardware and / or software for performing processing tasks. For example, the OBC may include one or more processors that execute instructions (data) stored in memory. Additionally or alternatively, the OBC may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other appropriate set of circuits that enable computer processing functionality.

[0044] On the other hand, the ground system 108 includes a ground station 110, which may include a payload control center (PCC) (also referred to herein as payload command and control, or payload command and controller) with modules for controlling the respective payloads of satellite 106. The PCC may communicate with a TC / TM / TD router or manager for managing routing commands and other messages, instead of the ground station 110.

[0045] The terrestrial station 110 may further include an SDR interface having one or more antennas to enable an S-band and / or X-band and / or UHF "communication link" with the corresponding S-band and / or X-band and / or UHF interface and antenna of the satellite 106. The terrestrial station 110 may include a database for storing TC / TM COB (Center of Box) information. Similar to the satellite 106, the terrestrial station 110 includes a dedicated agent 116 that implements various advantageous functionalities described herein, including but not limited to multi-tenant use of satellite resources. As shown, the agent 116 may include some of the same or similar modules as the agent 112 (not repeated again for brevity). The agent 116 further includes a database DB that stores TC, TM, and related information.

[0046] The ground station 110 may further include or communicate with a Mission Flight Command and Control (MFCC) module. A user of the ground system 108 may interact (provide input and display or receive output) with elements of the ground station 110 via a User Experience / User Interface (UX / UI) Control and Configurator (UXICC) corresponding to one or more input devices (keyboard, mouse, touch display, microphone, etc.) and one or more output devices (display, speaker, etc.). That is, the UXICC module includes graphical user interface (GUI) controls and interfaces commonly found or used in a web browser, mobile phone, tablet device, and / or server. In some examples, the UXICC receives input from a user / administrator, converts the input into a JSON file or other appropriate file format, and transmits the converted input to the MFCC and / or PCC. In particular, the user may configure and schedule the TC via the UXICC. The user may schedule the TC for a single satellite (unicast), a group of satellites (multicast), or all satellites (broadcast). On the receiving side, the UXICC receives telemetry data and displays the telemetry data on a dashboard selected by the user.

[0047] As can be understood, the ground system 108 including the UXICC, PCC, and / or MFCC is executed on one or more computing nodes. The computing nodes may be implemented on a stand-alone computer or cloud-based computing resources. As shown in FIGS. 2, 3, and 4, a single MFCC may communicate with a plurality of remotely located ground stations 110 represented by antennas 120. The MFCC itself may be included in one of the ground stations 110 or may be remote from all of the ground stations 110.

[0048] Although FIG. 1A shows a single terrestrial system 108, additional terrestrial systems 108 may be included in system 100, and each terrestrial system 108 includes components that are the same as or similar to those shown in FIG. 1A and is communicable with other remote terrestrial systems 108 (e.g., via the Internet or other suitable network connections). In the case of multiple terrestrial systems 108 as shown in the configuration of FIG. 1B, one or more terrestrial systems 108 may have only some of the functionality described with reference to FIG. 1A. For example, a terrestrial station 110 with reduced functionality may not include an S-band and / or X-band interface and instead may rely on the interface of another terrestrial station 110.

[0049] Regarding the various elements in FIGS. 1A and 1B and other figures, starting from the MFCC, they will be described in more detail below.

[0050] Generally, the MFCC is responsible for the encoding, management, timing, and scheduling of telecommands to satellite 106. In some examples, the UXICC may send requests to the associated MFCC module to transmit / schedule TC to a single satellite 106 (unicast), or a group of registered satellites 106 (multicast as shown in FIG. 2), or all registered satellites 106 (broadcast as shown in FIG. 3). The functionality of the MFCC for TC scheduling includes, but is not limited to, receiving requests to transmit TC to satellite 106 from the UXICC and / or PCC, and determining the next / nearest pass time of satellite 106 for the next / nearest ground station 110 that satellite 106 may contact. Here, the MFCC may have pre-configured knowledge about the ground station 110 and the satellite 106 endpoints. This knowledge may be changed dynamically - for example, if there is a new contract established to communicate satellite 106 with a new ground station 110, the details of the ground station 110 may be communicated to satellite 106 via TC. Additional functionality of the MFCC includes managing QoS, the uplink bandwidth available on the "communication link" between the ground station 110 and satellite 106 based on the next / nearest path of satellite 106, and prioritizing the TC based on one or more factors such as the TC waiting in the TC queue to be scheduled for satellite 106, and the priority or mission importance of each TC defined in the TC QoS configuration. Such priorities may be compared to the TC within the queue of one tenant mission, and / or the priorities may be compared to the TC within the queue across multiple tenant missions. Another factor affecting the priority may include the expiration time of the TC, which may correspond to the elapsed time since the TC entered the queue.

[0051] Other functions of the MFCC include encoding the TC according to the protocols and formats defined herein, ensuring the TC if required, selecting one or more antennas of the terrestrial station 110 to schedule the TC to the satellite 106, and managing broadcast and multicast scheduling. In the case of a broadcast or multicast TC request, a single TC request from the UXICC or PCC to the MFCC may be mapped to multiple satellites 106. In some examples, the MFCC prepares a list of satellites 106 intended to receive the TC, and based on the current state and position of the satellite 106 and the preconfigured "communication link" permissions of the terrestrial stations, the MFCC identifies a combination of one or more terrestrial stations 110 and satellite passage times, and designates the next / nearest terrestrial station, the satellite "communication link" passage time, and the "communication link" (e.g., in the form of a radio frequency antenna, an optical link, etc.) for transmitting the TC. Thereafter, the MFCC transmits the TC together with satellite identification information to the specified antenna, and the antennas transmit the TC to the specified satellite at their respective passage times. As shown in FIGS. 2 and 3, in that case, it should be understood that the MFCC can communicate with one or more antennas 120.

[0052] If there are multiple MFCCs, each MFCC may be present on different computing nodes, which can be cloud-based, dedicated servers, or other computing devices, and the MFCCs may communicate with each other as shown in FIG. 4 and adjust with each other to find the next / nearest terrestrial station 110 and satellite passage times, which helps to achieve optimal scheduling of the transmission.

[0053] In some examples, one or more MFCCs may schedule the same TC for transmission across multiple terrestrial stations 110 for redundancy and guaranteed timely TC transmission. Further, the MFCC may schedule the TC of a dedicated relay satellite using the satellite 106 with which the MFCC is communicating. The scheduled TC may be unicast, broadcast, or multicast.

[0054] The MFCC may further manage TC ACK and NAK on behalf of the ground station to verify the success or failure of TC transmission to satellite 106. For example, antenna 120 may fail to communicate a TC or other signal to satellite 106, in which case antenna 120 sends a NAK to the MFCC. Thereafter, the MFCC may attempt to reschedule the TC (e.g., if a "communication link" level failure occurs at antenna 120). In some examples, the attempt to reschedule the TC may be based on QoS criteria associated with the TC, and the QoS criteria may be adjusted compared to the original (failed) transmission. The number of attempts to reschedule a particular transmission may be configurable at the MFCC, with or without user instruction. Upon rescheduling, the MFCC may re-identify the next / nearest ground station and satellite pass time and then initiate a TC transmission request to antenna 120. As a result, the initial (failed) transmission and subsequent rescheduling of the transmission need not pass through the same antenna 120, nor through the same ground station 110.

[0055] On the other hand, the MFCC manages the TC ACK (if valid) received from satellite 106 when the transmission is successful. In some cases, the MFCC manages timeout events and retransmission of critical TCs (if required by TC QoS). Here, if no response / ACK is received from satellite 106 for the transmission and antenna 120 indicates transmission success, the MFCC times out and considers it a transmission failure at the application layer level and attempts to reschedule the transmission. The elapsed time until a timeout is determined to have occurred is configurable, with or without user input. For example, the amount of time may be determined based on the scheduling of satellite and ground station pass times. In addition, the number of attempts to reschedule the transmission in response to detection of a timeout may be configurable, with or without user input. As can be understood, the MFCC may notify the user through the UIXCC about the scheduling / transmission success or failure of the TC or other types of transmissions.

[0056] Additional functionality of the MFCC includes identifying non-responses from satellite 106 and initiating recovery processing. The MFCC may also process TC errors.

[0057] The MFCC may manage telemetry (TM) data received from satellite 106. Generally, TM data includes measurements and readings used to determine the health and status of satellite 106. Some exemplary functionality of the MFCC for processing TM data includes, but is not limited to, authentication and decoding (if necessary) and / or decryption of the TM data. The MFCC may also identify registered modules / services to which the TM data is transferred. Here, multiple modules / services may be registered for the TM data from satellite 106. For example, both a satellite diagnosis / health monitoring service and a remote debugging service may receive the same TM data from the satellite. As can be understood, the MFCC may transfer the TM data to the UXICC for dashboard display and transfer any PCC-related TM data to the PCC module. In a multi-tenant scenario where multiple users can access the same satellite, the administrator or user of each tenant can subscribe to mission / service-specific TM data, in which case the MFCC transfers the relevant TM data to the corresponding registered tenant administrator / user / service. The MFCC may also handle beacon monitoring, timeouts, and error handling, as well as duplicate detection and filtering.

[0058] The PCC is responsible for processing (processing, transferring, and routing) all received data (e.g., telemetry data TD) from the payload of satellite 106. The PCC may manage various payload activities of the payload present on satellite 106. The PCC may manage mission-specific and payload-specific TC and TM data. In some examples, the PCC may receive a TC request from the UXICC, and the PCC may request and initiate a telecommand through the MFCC. Since satellite 106 is multi-tenant capable, the PCC may encode mission-specific TC and protect (authenticate and encrypt / decrypt) the TC by using secret keys and / or public security keys generated by or provided to the PCC. In some examples, the PCC interprets the input provided by the UXICC, generates a message, and then depends on the MFCC to encode the message to enable secure communication of the message. On the receiving side, the PCC receives PCC-related telemetry data from the MFCC.

[0059] Figure 7 shows various elements from Figure 1A and further emphasizes how the OBC can include a telecommand and telemetry (TC / TM) manager. In some examples, the TC / TM manager is at least part of or included in agent 112. As shown in Figure 7, the TC / TM manager communicates with the SDR of satellite 106. The TC / TM manager is responsible for processing commands received from various ground segment entities and payload entities. The TC / TM manager may further process TC and TM data TM received via one or more ISCLs. As illustrated, the TC / TM manager is connected to a payload server and OBC applications to manage various operations and functionality. The TC / TM manager may transfer received commands from ground segment entities and the ISCL to the payload server and edge server or other hardware or software of satellite 106. The TC / TM manager may manage TC received from ground station 110 and / or the ISCL and schedule TM data on behalf of the satellite. Although not explicitly shown, ground station 110 may include its own TC / TM manager as at least part of agent 116.

[0060] The functionality of the TC / TM manager includes, but is not limited to, receiving TC via the ISCL from the ground station 110 and / or other satellites 106, authenticating and decrypting (if necessary) and decoding (if necessary) the TC, identifying registered modules / services to which the TC is to be transferred or routed (multiple modules / services such as ADCS, payload server, edge server, other satellites, etc. may register with the TC), and transferring the TC to the identified modules / services. The TC / TM manager may perform duplicate detection of TC and other error handling functions, and may identify and manage the next pass time of the next ground station that the satellite 106 contacts. Similar to the MFCC and PCC, the TC / TM manager has prior configuration information regarding the ground station and the satellite 106 to assist in identifying and managing the next pass time (the time when the satellite can reach the ground station), and such information may be dynamically changed via the TC. For example, if there is a new contract established to "communicate link" the satellite 106 with a new ground station 110, the details of the ground station 110 may be sent to the satellite 106 using the TC.

[0061] In some examples, the TC / TM manager identifies and manages the availability of the ISCL and schedules / relays / routes TC, TM data, or TD for other satellites via the ISCL. For example, the TC / TM manager may encode TC, TM, and / or TD messages transmitted to other satellites 106 via the ISCL. In particular, each tenant or user accessing satellite 106 can specify specific parameters for transmitting TC, TM, and TD messages, such as the type of encoding used. If the encoding satellite 106 has multiple ISCLs, the TC / TM manager can select from existing ISCLs based on the QoS and transmission requirements of the TC, TM, and / or TD messages (broadcast transmission, multicast transmission, and the requirements for QoS parameters are conveyed in the TC / TM / TD header fields, - additionally or alternatively, one or more of the transmission requirements and QoS parameters may be preconfigured before launch and / or transmitted as another TC while the satellite is in orbit). If it is necessary to relay or route mission / temporally critical messages, the TC / TM manager may transmit the messages multiple times (e.g., consecutively) to ensure successful transmission. In some examples, the TC / TM manager monitors transmission failures of the ISCL and processes retransmission of messages via the same or different ISCLs. Here, the number of retransmissions may be based on QoS requirements. If some confirmation response or similar response is expected from the receiving side of the ISCL satellite, the TC / TM holds a timer for receiving the confirmation response and processes timeout determination and retransmission of messages via the ISCL. Note that the time until detection of the transmission timeout and the number of retransmissions may be set with or without user input. The TC / TM manager may process ACK or response (data) at the relay satellite (e.g., satellite 1 transmits ISCL TC to satellite 2, and satellite 2 relays / routes the TC to satellite 3 - when the transmission of the TC to satellite 3 is successful, satellite 2 may send a response or ACK to satellite 1 confirming the successful transmission of the TC to satellite 3). The TC / TM manager may maintain one or more databases for storing details of the ground stations and satellite networks described herein.

[0062] In some cases, the TC / TM manager manages QoS and assigns priorities to TM data and / or TDs based on the available bandwidth and the TM data and / or TDs waiting in the queue to be scheduled for the ground station 110 or another satellite 106. The TC / TM manager may encode the TM data and / or TDs and protect messages as necessary according to the protocols defined and described herein. The TC / TM manager may schedule the TM data and / or TDs to the ground station 110 and / or another satellite 106 via the ISCL. The TC / TM manager may further schedule an ACK for the received TC (if valid). The TC / TM manager may further manage timeouts and retransmission of critical TM data (if necessary or requested), detect and exclude duplicate received TC / TM / TD packets, and schedule a beacon to the ground station 110 for keep-alive. The TC / TM manager may further identify a long-term lack of response or "communication link" from any of the ground stations 110 and the ISCL, initiate recovery processing, and handle TM data errors.

[0063] Exemplary embodiments regarding the content and management of databases in satellite 106 and ground station 110 will be described in more detail below. A set of database information in satellite 106 includes geographical location information of ground stations and satellite pass time information based on the current orbit of the satellite. The database may have entries for all ground stations 110 that satellite 106 may pass or come into contact with during its orbital revolution. The database may include information indicating which of the ground stations 110 are permitted to communicate with satellite 106 and which are restricted from communication. Such restricted ground stations may be made unable to communicate with satellite 106 except in critical situations or emergencies. Criteria for important and emergency communications are stored in the database and can be configured in advance or updated in real time through TC. Generally, the information in the database is pre-configured before launch and / or updated through TC when satellite 106 is in orbit.

[0064] While in orbit, satellite 106 may perform a full orbit scan to detect new and existing ground station "communication links". The scan period may vary and be selectable regardless of the presence of user input (e.g., scan once every 30 days). Additionally or alternatively, the scan may be triggered as part of a TC transmission and / or when there is time-critical or urgent data to be transferred to ground station 110.

[0065] Satellite 106 can further store information regarding the available and acceptable downlink bandwidth and uplink bandwidth of a particular ground station 110, and such information is updated when the functionality of ground station 110 changes. The satellite may store information identifying other satellites with which a particular ground station can communicate in the form of a Ground Station Client Satellite (GSCS) List (GSCSL). The GSCSL can convey the functionality of each satellite 106 on the list, and the list may include the relative orbital times and distances to each ground station, whether a particular satellite 106 is permitted to communicate with ground station 110, and the available uplink and downlink bandwidths. Satellite 106 may store information regarding the number of ISCL antennas, RF parameters, and acceptable and available ISCL bandwidths of other satellites. In some cases, satellite 106 stores mission parameters and the processing / computing capabilities (e.g., information regarding shareable computing resources) of other satellites 106.

[0066] The satellite can maintain a Neighboring Satellite Network List (NSNL), which may include information regarding nearby satellites having ISCL functionality. Each time satellite 106 contacts a neighboring satellite via ISCL, information regarding the neighboring satellite may be stored for future reference. Such information may include the ID of the neighboring satellite, the current position and orbital parameters of the neighboring satellite (which enables calculation of relative positioning and ISCL contact points and transit times), ISCL communication parameters, "communication link" quality, available and acceptable bandwidths via ISCL, available and acceptable bandwidths from the neighboring satellite to the ground station, the mission functionality of the neighboring satellite, the processing / computing (shareable) capabilities of the neighboring satellite, and any other such information that may support or facilitate each other's satellite missions.

[0067] The neighboring satellite may also share / exchange the terrestrial network database with other satellites 106. If the neighboring satellite is a relay-only satellite (ROS), and the ROS cannot communicate with its terrestrial station, the ROS may not maintain the terrestrial network database. However, for message relay or routing, if the neighboring satellite can communicate with the terrestrial station, the neighboring satellite may use the terrestrial network database of satellite 106. Also, the neighboring satellites may exchange NSNLs. Satellite 106 may track the updates of the NSNL. For example, satellite 106 may send the updated NSNL to other satellites via the ISCL. In another example, satellite 106 shares the updated NSNL with the terrestrial station 110, and then the terrestrial station 110 communicates the updated list to other authorized satellites 106 via unicast, broadcast, or multicast transmission.

[0068] Satellite 106 may generate a routing table that can identify the shortest and most reliable "communication link" for sending messages (e.g., messages containing TC, TM data, or TD) using the information described above and stored therein. The "communication link" can be either between the terrestrial station 110 and satellite 106 and / or between satellites that improve inter-satellite communication by forming a dynamic satellite mesh network (SMN) in space. The SMN and the real-time network routing table may provide reduced latency and more efficient and flexible transmission.

[0069] As shown in FIGS. 1A and 6, the OBC of satellite 106 includes OBC applications, sessions, and schedulers, which can play a role in managing some of the flight control-specific activities and mission-specific activities in response to the requirements of the payload, payload server, and / or edge server. The OBC also manages satellite diagnosis, health monitoring, power management, ADCS control, housekeeping, and payload monitoring. General satellite positioning requirements, such as nadir pointing, sun tracking, imaging direction, maximum power tracking, and other similar commands, are scheduled and managed by the OBC application.

[0070] The ADCS maintains the attitude of satellite 106 on the desired orbit. The ADCS continuously generates sensor-actuator data as telemetry information. The ADCS also receives specific pointing requests through telecommands from the payload or payload server. The ground station 110 can also query specific data from the ADCS through the TC / TM manager of satellite 106. The ADCS refers to the attributes of the ISCL and NSNL, NSRT, and operates the orientation of the satellite to establish an "communication link" with the ISCL of neighboring satellites and / or the GS.

[0071] The EPS / PDN is responsible for power distribution, solar-based battery charging, temperature monitoring, battery health monitoring, and various important power-related parameters. The EPS / PDN transmits information on these parameters to the ground station 110 as telemetry messages through the TC / TM manager.

[0072] The payload server is a notable element when considering its role as a distributed computing node within the space segment of System 100. The payload server manages the connected payloads, missions, and operational concepts. The payload server distributes received commands from the TC / TM manager to specific payloads. The payload server also collects data from various payloads and, in some cases, processes it (recall that payloads generally execute multiple functions scheduled and requested by the PPC in response to various mission-specific sensors and actuators). On the other hand, the edge server hosts multiple edge applications and processes data from payloads mounted on satellites and other sources.

[0073] Examples of the exchange categories for TC, TM, and TD are shown in Table 1 below. Table 1: Command and Data Exchange Categories for TC and TM

Table 1

[0074] With regard to the transmission, termination, encapsulation, decapsulation, and transfer / routing of TC, TM data, and TD via the uplink (UL) and downlink (DL), the exemplary roles of the various modules shown and described with reference to FIGS. 1A and 6 are shown in Table 2 below. Table 2: Module Rules for the Ground Segment and Space Segment

Table 2

[0075] The TC, TM data, and TD protocols according to the exemplary embodiments have the following high-level characteristics. The source of the commands can be any entity among the ground station 110, the satellite 106, or the neighboring satellite 106.2. This protocol is independent of the RF band and vendor radios. The underlying RF / baseband L2 / L1 protocol processes attributes such as frame synchronization and retransmission. Both the telecommand and telemetry frames indicate a "start of frame" (SOF), facilitating the reception and decoding of multiple packets on the receiving side. Each command may have a delayed response (since the command may request the execution of some action on the satellite), and also, one command may have multiple responses (e.g., periodic actions executed on the satellite for a particular command). Responses are transmitted through telemetry messages, while telemetry data messages are used mainly to transmit mission-specific payload data as a response to telecommands. The protocol also supports security functions such as encryption, decryption, and authentication functions - these functions are optional and may be enabled or disabled at the individual command level. QoS can be ensured for various applications by having regulated centralized scheduling, and the requesting module may specify the QoS required for any command to be scheduled. A single TC frame transmits a single TC, but depending on the available bandwidth of the "communication link", multiple TC frames may be packed back-to-back into a single RF packet. Due to the SOF and frame length of the TC frame, the receiver can decode each TC frame by demarking the SOF of each TC frame.

[0076] The source of the message may be from segments mounted on the ground or on the satellite - the TC mounted on the satellite may follow the same frame format as described above. The destination of the message may be either a single destination (unicast) or multiple destinations (broadcast or multicast) are possible.

[0077] FIG. 8 shows an example of the TC frame format, and Table 3 and the following related descriptions define the fields shown in FIG. 8. Table 3: TC Frame Field Information

Table 3

[0078] The start of frame (SOF) helps detect the first byte of the frame structure and reduces the computing requirements for searching. The SOF may be 1 byte in size and holds the value 0xA5 as the default. The TC control holds information necessary for decoding telecommand data and is 1 byte in size. Table 4 shows the various possibilities of the TC control field. Table 4: TC Control Field Information

Table 4

[0079] The mission control center (MCC) field in Table 3 specifies the MCC control field command domain and is an option based on TC control b’6. The MCC version is a field that includes the MCC version being used and is also based on TC control b’6.

[0080] The mission / sensor type field includes the mission and sensor types being used. This field is an option based on TC control b’6. The timestamp field includes the UTC timestamp when the ground station 110 transmitted the TC command. The sequence No holds the sequential increasing message sequence number and is maintained by the transmitter of the TC message.

[0081] The SAT Id refers to the unique identifier of a specific satellite or satellite group. In the case of a satellite group, the group satellite Id may be obtained during the scheduling of the multicast TC. The SAT Id facilitates both the unicast mode and the multicast mode of the message and can be 1 byte or 2 bytes in size. The extended bit (7th bit) of the first byte indicates the availability of the second byte. On the other hand, the GS Id is a field that includes the unique identifier of a specific ground station through which the TC passes and may be 1 byte or 2 bytes. The extended bit (7th bit) of the first byte indicates the availability of the second byte.

[0082] The QoS field contains information for determining the priority of the TC message transmitted from ground station 110 to satellite 106 in order to provide better service to priority applications and ranges from 0 to 255. The higher the QoS value, the higher the priority.

[0083] The source application (SA) Id identifies the source entity from which the message was sent. For example, the source may be PCC, MFCC, or the payload. The SA Id field is 1 byte or 2 bytes, and the extended bit (7th bit) of the first byte indicates the availability of the second byte.

[0084] The destination application (DA) Id refers to the final destination entity to which the TC message needs to reach. For example, the destination module may be ADCS, OBC, EPS / PDN, payload server, payload, etc. The DA Id is 1 byte or 2 bytes, and the extended bit (7th bit) of the first byte indicates the availability of the second byte.

[0085] The TC Id is a field containing unique commands with their own parameters. Each telecommand Id belongs to multiple categories of messages in various modules and functions of satellite 106. For example, there are several commands in the ADCS module, and each command may be assigned a TC Id. The size of the TC Id is 1 byte, but it can be extended to 2 bytes if necessary.

[0086] The TC length (TC Len) refers to the total size of the parameters related to a given TC Id in the current frame. The size of the length field is 1 byte or 2 bytes, and the extended bit (bit 7) of the first byte indicates the availability of the second byte.

[0087] The TC data field contains a variable set of parameters (type, length, value) for a given TC Id in TLV (type, length, value) format. Each parameter is pre-agreed to be used by both the source entity and the destination entity.

[0088] The CRC field contains the checksum of a given frame, including from the SOF to the end of the TC payload.

[0089] The CMAC / HMAC field contains an encryption-based authentication code (CMAC) and / or a hash-based authentication code (HMAC) used to protect the TC message.

[0090] Figure 9 shows an example of the format of the telemetry TM frame, which will be described in more detail below with reference to Table 5. Table 5: TM Frame Field Information

Table 5

[0091] The start of frame (SOF) helps detect the first byte of the frame structure and reduces the computing requirements for searching. The SOF field is 1 byte in size and holds a default value of 0xA5.

[0092] TM control contains information necessary for decoding telemetry data and is 1 byte in size. Table 6 below shows this field in more detail. Table 6: TM Control Field Information

Table 6

[0093] The MCC field specifies the domain of the MCC control command. This field is an option based on TM control b’6. The MCC version field contains the MCC version being used and is also an option based on TM control b’6.

[0094] The mission / sensor type field contains the mission and sensor type being used. This field is an option based on TC control b’6. The timestamp field contains the UTC timestamp when the satellite transmitted the TM message. The sequence No holds the sequential message sequence number that increases continuously for each TM message and is maintained by the sender of the TM message.

[0095] SAT Id contains the unique identifier of the satellite transmitting the TM message. The extended bit (bit 7) of the first byte indicates the availability of the second byte.

[0096] The QoS field contains information for determining the priority of the TM message transmitted from satellite 106 to ground station 110 to provide better service for priority applications and ranges from 0 to 255. The higher the QoS value, the higher the priority.

[0097] The Source Application (SA) Id identifies the source entity from which the message was sent. For example, the source may be ADCS, OBC, EPS / PDN, Payload Server, Payload, etc. The SA Id field is 1 byte or 2 bytes, and the extended bit (bit 7) of the first byte indicates the availability of the second byte.

[0098] The Destination Application (DA) Id identifies the final destination entity to which the TM message needs to reach. For example, the destination may be PCC, MFCC, and / or another element of the terrestrial system 108. The DA Id is 1 byte or 2 bytes, and the extended bit (bit 7) of the first byte indicates the availability of the second byte.

[0099] The TM Id contains the unique telemetry value associated with a group of telemetry parameters. Each telemetry Id belongs to multiple categories of data collected from various modules of the satellite 106. In some but not all cases, the TM Id is the same as the TC Id of the TC command to which the TM message is a response. The size of the TM Id may be 1 byte.

[0100] The TM Length (TM Len) is a field that identifies the total size of the parameters associated with a given TM Id in the current frame. The size of the TM length field is 1 byte or 2 bytes, and the extended bit (bit 7) of the first byte indicates the availability of the second byte.

[0101] The TM Data is a field that contains a variable set of parameters for a given TM Id in TLV (Type, Length, Value) format. Each parameter is in a pre-agreed format that is used by both the source entity and the destination entity.

[0102] The CRC field contains the checksum of a given frame, including from the SOF to the end of the TM payload.

[0103] The CMAC / HMAC field includes an encryption-based authentication code (CMAC) and / or a hash-based authentication code (HMAC) used to protect the TM message.

[0104] Figure 10 shows an example of the format of the TD frame, which will be described below with reference to Table 7. Table 7: TD Frame Field Information

Table 7

[0105] The start of frame (SOF) helps to detect the first byte of the frame structure and reduces the computing requirements for searching. The SOF field is 1 byte in size and holds the value 0xA5 as the default.

[0106] TM control contains the information necessary for decoding telemetry data and is 1 byte in size. Table 8 below shows this field in more detail. Table 8: TD Control Field Information TIFF2025524244000009.tif88152

[0107] The MCC field specifies the domain of the MCC control command. This field is an option based on TM control b’6. The MCC version field includes the MCC version being used and is also an option based on TM control b’6.

[0108] The mission / sensor type field includes the mission and sensor type being used. This field is an option based on TC control b’6. The timestamp field includes the UTC timestamp when the satellite transmitted the TD message. The sequence No holds the sequential message sequence number that increases continuously for each TD message and is maintained by the sender of the TD message.

[0109] The SAT Id includes the unique identifier of the satellite or satellite group that transmits the TD message. The first byte's extension bit (the 7th bit) indicates the availability of the second byte.

[0110] The QoS field contains information for determining the priority of message exchange transmitted from satellite 106 to ground station 110 in order to provide better service for priority applications, and it ranges from 0 to 255. The higher the QoS value, the higher the priority.

[0111] The Source Application (SA) Id identifies the source entity from which the message is originated. For example, the source may be a payload server, an edge server, a payload, a logger, etc. The SA Id field is 1 byte or 2 bytes, and the first byte's extension bit (the 7th bit) indicates the availability of the second byte.

[0112] The Destination Application (DA) Id identifies the final destination entity to which the TD message needs to reach. For example, the destination may be the PCC, MFCC, and / or another element of the terrestrial system 108. The DA Id is 1 byte or 2 bytes, and the first byte's extension bit (the 7th bit) indicates the availability of the second byte.

[0113] The TD Id includes the unique ID related to telemetry data. For example, if a particular mission has two or more categories of data to transmit, this field is used to distinguish the categories. The size of the TD Id may be 1 byte.

[0114] The TD Length (TD Len) is a field that identifies the total size of the parameters related to a given TD Id in the current frame. The size of the TD length field is 1 byte or 2 bytes, and the first byte's extension bit (the 7th bit) indicates the availability of the second byte.

[0115] TD data is a field that contains a variable set of parameters for a given TD Id in the TLV (Type, Length, Value) format. Each parameter is in a pre-agreed format that is used by both the source entity and the destination entity.

[0116] The CRC field contains the checksum of a given frame, including from the SOF to the end of the TD payload.

[0117] The CMAC / HMAC field contains an encryption-based authentication code (CMAC) and / or a hash-based authentication code (HMAC) used to protect the TD message.

[0118] Figures 11 to 14 are message diagrams showing transmission messages in various scenarios. For example, Figure 11 shows starting a TC from the MFCC, Figure 12 shows starting a TC from the PCC and receiving a TD via the X-band interface, Figure 13 shows starting a TC from the PCC via the S-band and receiving TM data via the S-band, and Figure 14 shows starting a multicast or broadcast TC from the PCC.

[0119] It should be understood that the steps shown in these message diagrams and any other methods described herein are for illustrative purposes only and do not limit the scope of the present disclosure. More or fewer steps than those illustrated may be performed, and in some cases, they may be performed in an order different from that shown in the figures. For example, although the figures show the generation of an ACK for the success of a transmission or the completion of a command, it should be understood that a NAK may be generated instead in the case of a transmission failure or when the payload fails to execute the command. Some steps may occur substantially simultaneously, and some steps may be performed by elements other than those shown. The methods from FIGS. 11 to 14 and other methods described herein may be performed in accordance with the above-described TM data, TC, and TD protocol formats. Although not explicitly explained in all cases, it should be understood that a specific request or receipt of a transmission in one step automatically triggers the next step.

[0120] Figure 11 shows steps 1100 through 1160 for starting a TC from MFCC. At 1100, in the UXICC, the user makes one or more inputs to the UXICC to start a TC, such as a command for ADCS control. At 1104, the MFCC encodes the TC and transmits the encoded command (one or more TC frames) to the ground station 110. At 1108, the ground station 110 transmits the encoded command to the SDR of the satellite 106 via the S-band interface, where the command is decoded. At 1116, the satellite SDR transmits an encoded confirmation response indicating that the command was successfully received to the ground station 110, and then at 1120 the ground station 110 decodes the confirmation response and transmits a notification of the confirmation response to the UXICC for the user. At 1128, the SDR transmits the decoded command to the TC / TM manager, and at 1132 the command is transferred to the OBC application. At 1136, the OBC application interprets the command and transmits corresponding control signals to the ADCS to execute the command. At 1140, the ADCS returns an acknowledgment response ACK indicating that the command was executed to the OBC application, and the OBC application transfers the ACK to the TC / TM manager at 1144. At 1148, the TC / TM manager encodes the ACK and transmits the encoded ACK to the SDR (e.g., as one or more TC frames). Thereafter, at 1152, the SDR transmits the encoded ACK to the corresponding S-band interface of the ground station 110 via the S-band interface. The ground station decodes the ACK and transmits the decoded ACK to the MFCC at 1156. Thereafter, the MFCC transmits a notification informing the user of the completed command and / or updated ADCS status to the UXICC at 1160.

[0121] Figure 12 shows steps 1200 through 1286 for starting a TC from the PCC and receiving a TD via the X-band interface. At 1200, the user starts a TC as a payload query in the UXICC and sends the query to the PCC. At 1204, the PCC generates a payload query message containing the TC and sends it to the MFCC. At 1208, the MFCC encodes the message as one or more TC commands and sends it to the ground station 110, and at 1216, it transmits it to the satellite SDR via the S-band interface. At 1220, the SDR generates an encoded acknowledgment response and sends it to the ground station 110. Thereafter, at 1222, the ground station 110 decodes the acknowledgment response and transfers the decoded acknowledgment response to the MFCC. The decoded acknowledgment response is transferred from the MFCC to the PCC at 1224 and then to the UXICC at 1228, notifying the user that the transmission from the ground station 110 to the satellite 106 was successful. At 1232, the SDR decodes the command and sends the decoded command message to the TC / TM manager, which transfers the decoded command message to the payload server at 1236. At 1240, the payload server interprets that the decoded message is for the ADCS and sends a request to the OBC application to establish a session with the ADCS. At 1244, the OBC application interprets the request, establishes a session with the ADCS, and requests the data requested by the query. In this example, the query requested data regarding the pointing position of the satellite 106 determined by the ADCS. Thus, at 1248, the ADCS sends data indicating the pointing position and an acknowledgment response indicating that the query is complete to the OBC application. The OBC application transfers the data and the acknowledgment response (the data itself may function as an ACK) to the payload server at 1252. At 1256, the payload server sends the data to the SDR's DL buffer bypassing the TC / TM manager. Immediately thereafter or substantially simultaneously, at 1260, the payload server schedules the DL transmission of the payload data and provides the scheduling information to the OBC application.At 1266, the OBC application sends a request to the TC / TM manager to trigger an X-band DL "communication link" (while bypassing the payload server). At 1270, the TC / TM manager generates a command in response to the request at 1266 (e.g., in TD frame format) and sends the DL-encoded command to the SDR where the payload data (telemetry data) is waiting in the buffer. At 1274, the SDR sends the encoded command signal with the payload data to the ground station 110, where the signal is decoded and the decoded payload data is provided to the MFCC at 1278. At 1282, the decoded payload data is sent to the PCC, and the PCC sends the payload data to the UXICC at 1286 for viewing and / or analysis by the user.

[0122] Figure 13 shows steps 1300 through 1360 for starting the TC from the PCC via the S band and receiving TM data via the "communication link" of the S band. At 1300, the user starts a payload query at the UXICC, and the UXICC sends the query to the PCC. The PCC generates a query message and sends the message to the MFCC at 1304. At 1308, the MFCC encodes the message (e.g., as one or more TC commands in the TC frame format) and sends it to the ground station 110. Thereafter, the ground station 110 sends a command to the satellite SDR via the S band interface at 1312. At 1316, the SDR returns an encoded ACK indicating the success of the command reception to the ground station 110. The encoded ACK is decoded by the ground station 110 at 1320 and transferred to the UXICC through the PCC at steps 1324 and 1328. On the other hand, at 1332, the SDR decodes the command and sends the decoded command or message to the TC / TM manager, and the TC / TM manager transfers a message containing a request for the data requested by the initial query to the payload server at 1336. The payload server processes the request at 1344 and returns data (e.g., TM data generated by processors, payloads, IOs, and other such hardware and software applications and resources) to the TC / TM manager. At 1344, the TC / TM manager encodes the data and sends the encoded data to the SDR (e.g., in the TM frame format). The SDR sends the encoded data to the ground station 110 at 1348 via the S band interface, and the ground station 110 decodes the data and sends it to the MFCC at 1352. Thereafter, at 1356, the MFCC sends the currently decoded data to the PCC, and the PCC sends the data to the UXICC at 1360 for viewing and analysis.

[0123] Figure 14 shows steps 1402 through 1454 for starting a multicast or broadcast TC from the PCC. At 1402, a user of the UXICC generates a request to send a multicast or broadcast transmission (command) and sends the request to the PCC. The PCC registers the request with the MFCC at 1404. At 1406, the MFCC assigns an ID to the transmission and returns the ID to the PCC. At 1408, the PCC sends the ID to the UXICC for display. At 1410, the user starts the TC using the ID, sends the TC to the PCC, and the PCC sends the TC to the MFCC. At 1416, the MFCC returns an ACK (which may also be sent to the UXICC) to the PCC indicating that the multicast or broadcast transmission request was successful. At 1418 and 1436, the MFCC generates two separate encoded (in the TC frame format) TC commands to be sent to the terrestrial station 110 (e.g., generated simultaneously). As shown, steps 1418 through 1434 are related to the first satellite and steps 1436 through 1454 are related to the second satellite. At 1420 and 1438, the SDRs send the two separate encoded commands to their respective satellite SDRs. In particular, the multicast or broadcast TC is generated as a single command at the MFCC, but is sent in two separate transmissions from the "communication link" layer (terrestrial station) taking into account the potentially different propagation times for each satellite. At 1422 and 1440, each SDR decodes the command and transfers the decoded command or message to its respective TC / TM manager, and each TC / TM manager interprets the command as a data request from the payload server at 1424 and 1442. At 1426 and 1444, each respective payload server returns the data requested from the payload server (the data itself may be an ACK) to the TC / TM manager. Thereafter, at 1428 and 1446, each TC / TM manager formats and encodes the data (e.g., in the TM or other appropriate frame format) and sends it to each SDR.At 1430 and 1448, each SDR sends the encoded data back to the terrestrial station 110 via its respective S-band interface, and the data is decoded at 1434 and 1452 and transferred to the MFCC before the UXICC receives the data at 1454 and / or updates the status information based on the received data from 1434 and 1452. Here, it should be understood that each satellite may be associated with the same MFCC or different MFCCs. In the case of different MFCCs, the MFCC of one satellite may transfer the TC from 1412 to the MFCC of the other satellite.

[0124] In view of the description and the drawings, it should be understood that an exemplary embodiment provides a satellite 106 comprising a "communication link" interface (X-band and / or S-band), at least one processor, and at least one memory (e.g., the processor and memory of the OBC). The at least one processor and the at least one memory are configured to support a plurality of tenant applications in a multi-tenant cloud computing environment. Two or more of the plurality of tenant applications establish independent "communication link" channels with a ground station using the "communication link" interface. For example, a first tenant application among two or more of the plurality of tenant applications establishes a first "communication link" channel, and a second tenant application among two or more of the plurality of tenant applications establishes a second "communication link" channel. The first "communication link" channel utilizes a different security protocol than the second "communication link" channel. For example, at least one of encryption and decryption is performed on the first "communication link" channel in a different manner than on the second "communication link" channel. In some cases, a different encryption key is used for the first "communication link" channel compared to the second "communication link" channel. In at least one embodiment, the satellite 106 is configured to transmit emergency telecommands to other satellites 106 via a side link (e.g., ISCL). In some examples, the emergency telecommands are transmitted to other satellites via the ground station 110. The emergency telecommands may be transmitted autonomously. In some cases, at least one of the plurality of tenant applications is configured to consume unallocated bandwidth from the "communication link" interface in response to the detection of an emergency. In some examples, at least one of the plurality of tenant applications is configured to offload tasks to other satellites. For example, a task is offloaded by transmitting mission and / or task information to other satellites via at least one of the ground station and the side link.At least one tenant application among a plurality of tenant applications shares information with other satellites, and the information includes satellite ID, current position and orbital parameters, side link "communication link" parameters, "communication link" quality via the side link, and available and allowed data bandwidths, "communication link" quality from neighboring satellites to a ground station "communication link" (download and / or upload) and available and allowed data bandwidths, mission functions of the satellite, sharable computing resources, sharable memory resources, sharable sensors, cameras, and any HW accelerators, and / or sharable battery power resources. The information is shared via at least one of the side link and the ground station. When the data stored in at least one memory is processed by at least one processor, the satellite is enabled to estimate the nearest and / or shortest side link path of neighboring satellites based on the orbital parameters of the neighboring satellites. The orbital parameters include at least one of relative orbital time, relative orbital distance, and the shortest network relay path. When the data stored in at least one memory is processed by at least one processor, the satellite is enabled to generate and maintain a shortest / nearest "communication link" path table. When the data stored in at least one memory is processed by at least one processor, the satellite is enabled to perform a ground station "communication link" (e.g., wireless link, optical link) scan to identify a new ground station or a new neighboring satellite.

[0125] In view of the above, at least one exemplary embodiment provides a system including a ground station and a satellite having a "communication link" interface, at least one processor, and at least one memory. The at least one processor and the at least one memory are configured to support a plurality of tenant applications in a multi-tenant cloud computing environment, and two or more of the plurality of tenant applications establish independent "communication link" channels with the ground station using the "communication link" interface.

[0126] In some embodiments, a satellite is provided that includes a payload that generates payload data, at least one processor, and at least one memory that includes data that enables the at least one processor to process commands from a plurality of users according to the same protocol and access the payload data, the payload, or both based on the processed commands.

[0127] Exemplary embodiments can be configured as follows. (1) A ground station comprising at least one processor and at least one memory that includes instructions that, when executed by the at least one processor, cause the at least one processor to generate commands for one or more satellites based on received requests, determine a time for communicating the commands to the one or more satellites based on the position of the one or more satellites relative to an antenna of the ground station, schedule the commands for transmission to the one or more satellites based on the type of transmission of the commands and the determined time, and a system including the same. (2) The system according to (1), wherein the commands are encoded. (3) The system according to one or more of (1) or (2), wherein the at least one processor reschedules the transmission of the commands when detecting a failure in the transmission of the commands to the one or more satellites. (4) The system according to one or more of (1) to (3), wherein the at least one processor schedules the commands for transmission from the ground station when the antenna of the ground station is at least one of the antenna closest to the satellite among the one or more satellites and the satellite having the shortest "communication link" transit time. ​(5) At least one processor communicates with another ground station and schedules a command for transmission from the other ground station if at least one of the following is true: an antenna of the other ground station is closer to a satellite among one or more satellites than the antenna of the ground station, and the other ground station has a shortest "communication link" transit time with the ground station, for one or more of the systems described in (1)-(4). (6) The command includes a header that identifies which of one or more satellites should execute the command, for one or more of the systems described in (1)-(5). (7) The type of command transmission method includes unicast transmission to a single satellite among one or more satellites, for one or more of the systems described in (1)-(6). (8) The type of command transmission method includes multicast transmission to some but not all of one or more satellites, for one or more of the systems described in (1)-(7). (9) The multicast transmission is scheduled at a layer of the ground station other than the "communication link" layer including the antenna, for one or more of the systems described in (1)-(8). (10) The "communication link" layer addresses individual satellites of one or more satellites when transmitting a command, for one or more of the systems described in (1)-(9). (11) The type of command transmission method includes broadcast transmission to all of one or more satellites, for one or more of the systems described in (1)-(10). (12) The command is authenticated by one or more satellites, for one or more of the systems described in (1)-(11). (13) At least one processor schedules a command for transmission to an intermediate satellite that relays the command to the destination satellite among one or more satellites, for one or more of the systems described in (1)-(12). (14) The command includes an identifier of the destination satellite that the intermediate satellite uses to transfer the command to the destination satellite, for one or more of the systems described in (1)-(13). (15) The ground station antenna is one or more of the systems described in (1) to (14), comprising an S-band transceiver for transmitting commands. (16) The ground station antenna is one or more of the systems described in (1) to (15), comprising an X-band transceiver for receiving payload data from one or more satellites. (17) At least one processor schedules commands for transmission based on an assigned quality of service related to an application that executes the commands, in one or more of the systems described in (1) to (16). (18) At least one processor receives and processes telemetry information and / or payload data from one or more satellites, one or more satellites further included, in one or more of the systems described in (1) to (17). (19) One or more satellites are configured to transfer commands to respective tenant applications of the satellites, in one or more of the systems described in (1) to (18). (20) One or more satellites are configured to transfer commands to another ground station based on a destination identifier included in the commands, in one or more of the systems described in (1) to (19). (21) One or more satellites are configured to transfer telemetry information and / or payload data to respective tenant applications of the satellites, in one or more of the systems described in (1) to (20). (22) At least one processor, and when executed by at least one processor, to the at least one processor, receive commands from a ground station; determine whether the command is for the satellite or for another satellite; if the command is for the satellite, transmit the command to at least one resource of the satellite to execute a function based on the command; if the command is for another satellite, transmit the command via an inter-satellite "communication link"; A satellite comprising at least one memory including instructions to cause execution thereof A system including (23) The system according to (22), further including one or more additional satellites including other satellites (24) The system according to one or more of (22) or (23), wherein at least one processor transmits commands to one or more additional satellites via an inter-satellite "communication link" such as a side link (25) The system according to one or more of (22) to (24), wherein at least one processor decodes and / or authenticates a command before transmitting the command via an inter-satellite "communication link" (26) The system according to one or more of (22) to (25), wherein at least one processor re-encodes a command before transmitting the command via an inter-satellite "communication link" (27) The system according to one or more of (22) to (26), wherein one or more additional satellites include relay-only satellites that do not communicate with a ground station (28) The system according to one or more of (22) to (27), wherein at least one resource corresponds to a payload server that manages multiple applications of multiple tenants, an edge server that hosts an edge application that processes data carried by the satellite, one or more systems that manage the power function of the satellite, and / or one or more systems that manage the positioning of the satellite (29) The system according to one or more of (22) to (28), wherein the instructions, when executed by at least one processor, include instructions to cause the at least one processor to collect and schedule transmission of satellite information to a ground station (30) The system according to one or more of (22) to (29), wherein the satellite information includes telemetry information and / or payload data collected by the satellite and / or one or more other satellites (31) The system according to one or more of (22) to (30), wherein the telemetry information and / or payload data are collected according to commands (32) The telemetry information and / or payload data are collected autonomously by one or more of the systems described in (22) to (31). (33) The telemetry information and / or payload data are collected by one or more of the systems described in (22) to (32) based on internal events and / or triggers of the satellite. (34) At least one processor encodes the satellite information before transmitting it to the ground station, in one or more of the systems described in (22) to (33). (35) One or more of the systems described in (22) to (34), further including a ground station. (36) Generating commands for one or more satellites based on inputs received through a user interface, and Scheduling commands for transmission to one or more satellites from a ground station selected from a plurality of ground stations based on the positioning and command transmission types of the one or more satellites, and Transmitting commands from the selected ground station to one or more satellites based on the scheduling. A method including the above. (37) Generating commands includes encoding the commands, in the method described in (36). (38) The commands cause at least one function commanded by the commands to be executed by one or more systems mounted on one or more satellites, in one or more of the methods described in (36) or (37). (39) One or more systems include at least one payload server that controls sensors of one or more satellites to collect payload data, at least one power management system that manages the power of one or more satellites, and / or one or more navigation systems that manage the positioning of one or more satellites, in one or more of the methods described in (36) to (38). (40) Receiving commands from a selected ground station by one or more satellites, and Decoding the received commands. Based on the decoded command, determining a destination system from among one or more systems, transferring the decoded command to the destination system, and further including, one or more methods among those described in (36) to (39). (41) Generating an acknowledgement response indicating that the destination system has executed a function according to the command and transmitting it to the selected ground station and further including, one or more methods among those described in (36) to (40). (42) Generating an acknowledgement response includes encoding the acknowledgement response, one or more methods among those described in (36) to (41). (43) The destination system collects satellite information according to the command, schedules the transmission of the satellite information to one or more of the plurality of ground stations, and transmits the satellite information to one or more ground stations based on the schedule, and further including, one or more methods among those described in (36) to (42). (44) The satellite information includes telemetry information and / or payload data, one or more methods among those described in (36) to (43). (45) Encoding the satellite information before transmitting the satellite information and further including, one or more methods among those described in (36) to (44). (46) The command and the acknowledgement response related to the command are transmitted via the S band and / or other "communication links" / air interfaces, and the satellite information is transmitted via the X band and / or other "communication links" / air interfaces, one or more methods among those described in (36) to (45). (47) The type of command transmission is one of unicast transmission to a single satellite among one or more satellites, multicast transmission to some but not all of one or more satellites, and broadcast transmission to all satellites among one or more satellites, one or more methods among those described in (36) to (46). (48) The "communication link" interface, At least one processor and at least one memory, A satellite comprising: The at least one processor and the at least one memory are configured to support a plurality of tenant applications in a multi-tenant cloud computing environment, and two or more of the plurality of tenant applications establish a communication link channel separated from a ground station using a "communication link" interface. Satellite. (49) A first tenant application among two or more of the plurality of tenant applications establishes a first "communication link" channel, and a second tenant application among two or more of the plurality of tenant applications establishes a second "communication link" channel, and the first "communication link" channel utilizes a security protocol different from that of the second "communication link" channel. The satellite according to (48). (50) The first "communication link" channel is subjected to at least one of encryption and decryption in a manner different from that of the second "communication link" channel. One or more of the satellites according to (48) or (49). (51) A different encryption key is used for the first "communication link" channel as compared to the second "communication link" channel. One or more of the satellites according to (48) to (50). (52) The satellite is configured to transmit an emergency telecommand to another satellite. One or more of the satellites according to (48) to (51). (53) The emergency telecommand is transmitted to another satellite via a side link. One or more of the satellites according to (48) to (52). (54) The emergency telecommand is transmitted to another satellite via a ground station. One or more of the satellites according to (48) to (53). (55) The emergency telecommand is transmitted autonomously. One or more of the satellites according to (48) to (54). At least one tenant application among a plurality of tenant applications is configured to consume unallocated bandwidth from a "communication link" interface in response to detection of an emergency, one or more satellites as described in (48)-(55). (57) At least one tenant application among a plurality of tenant applications is configured to offload a task to other satellites, one or more satellites as described in (48)-(56). (58) The task is offloaded by transmitting mission and / or task information to other satellites via at least one of a ground station and a sidelink, one or more satellites as described in (48)-(57). (59) At least one tenant application among a plurality of tenant applications shares information with other satellites, and the information is - satellite ID, - current position and orbital parameters, - sidelink "communication link" parameters, - "communication link" quality, available and allowed data bandwidth via the sidelink, - "communication link" quality, available and allowed data bandwidth from neighboring satellites to the GS "communication link" (download and / or upload), - mission functions of the satellite, - sharable computing resources, - sharable memory resources, - sharable sensors, cameras, and any HW accelerators and - sharable battery power resources, including data selected from (48)-(58), one or more satellites as described in (48)-(58). (60) The information is shared via at least one of a sidelink and a ground station, one or more satellites as described in (48)-(59). (61) The information is also shared with a ground station, one or more satellites as described in (48)-(60). When the data stored in at least one memory is processed by at least one processor, it enables a satellite to estimate the nearest and / or shortest sidelink path of neighboring satellites based on the orbit parameters of the neighboring satellites, the satellite being one or more of those described in (48) to (61). (63) For one or more of the satellites described in (48) to (62), the orbit parameters include at least one of relative orbit time, relative orbit distance, and the shortest network relay path. When the data stored in at least one memory is processed by at least one processor, it enables a satellite to generate and maintain a shortest / nearest "communication link" path table, the satellite being one or more of those described in (48) to (63). When the data stored in at least one memory is processed by at least one processor, it enables a satellite to perform a ground station "communication link" scan and identify a new ground station, the satellite being one or more of those described in (48) to (64). When the data stored in at least one memory is processed by at least one processor, it enables a satellite to perform a ground station "communication link" scan and identify a new neighboring satellite, the satellite being one or more of those described in (48) to (65). When the data stored in at least one memory is processed by at least one processor, it enables a satellite to schedule multiple redundant transmissions of a telecommand to a destination via a "communication link" interface, and the multiple redundant transmissions of the telecommand are transmitted via different ground stations, the satellite being one or more of those described in (48) to (66). When the data stored in at least one memory is processed by at least one processor, it enables a satellite to identify resource sharing and / or changes in orbit parameters and "communicate" the changes to at least one other satellite via a "communication link", the satellite being one or more of those described in (48) to (67). (69) A ground station, a satellite, A system comprising: The satellite is equipped with a "communication link" interface and at least one processor and at least one memory, and the at least one processor and the at least one memory are configured to support a plurality of tenant applications in a multi-tenant cloud computing environment, and two or more of the plurality of tenant applications establish a "communication link" channel separated from the ground station using the "communication link" interface. System. (70) A payload that generates payload data, at least one processor, and at least one memory that includes data that enables the at least one processor to process commands from a plurality of users according to the same protocol and access payload data, the payload, or both based on the processed commands. Satellite comprising the same. (71) The satellite performs internal monitoring of shareable computing resources, shareable memory resources, shareable sensors, cameras, any HW accelerators, payloads, shareable battery power resources, and at least one of the plurality of tenant applications. The satellite generates data related to the internal monitoring and communicates the data to one or more neighboring satellites through at least one of an inter-satellite communication link (ISCL) and a ground station via a ground communication link. The satellite according to (59). (72) The satellite generates a routing table indicating the characteristics of the shortest communication link between the satellite and one or more of one or more neighboring satellites. The satellite dynamically updates the routing table based on at least one of information received from one or more of one or more neighboring satellites, information received from the ground station, and internal calculations of the positions of neighboring satellites. The satellite according to (59). (73) The satellite generates a routing table indicating the characteristics of the shortest communication link between the satellite and one or more of the ground stations via the inter-satellite communication link (ISCL) of neighboring satellites, and the satellite dynamically updates the routing table based on information received from one or more of the one or more neighboring satellites, and / or information received from the ground stations, and / or internal calculations of the positions of the neighboring satellites, the satellite as described in (59).

Claims

1. A communication link interface, at least one processor and at least one memory, A satellite comprising: The at least one processor and the at least one memory are configured to support a plurality of tenant applications in a multi-tenant cloud computing environment, and two or more of the plurality of tenant applications establish independent communication link channels with a ground station using the communication link interface. A satellite comprising the above.

2. A first tenant application among the two or more of the plurality of tenant applications establishes a first communication link channel, and a second tenant application among the two or more of the plurality of tenant applications establishes a second communication link channel, and the first communication link channel uses a security protocol different from that of the second communication link channel. The satellite according to claim 1.

3. The first communication link channel is encrypted and / or decrypted in a different way from the second communication link channel. The satellite according to claim 2.

4. A different encryption key is used for the first communication link channel compared to the second communication link channel. The satellite according to claim 2.

5. The satellite is configured to transmit an emergency telecommand to another satellite. The satellite according to claim 1.

6. The emergency telecommand is transmitted to the other satellite via a sidelink. The satellite according to claim 5.

7. The emergency telecommand is transmitted to the other satellite via a ground station. The satellite according to claim 5.

8. The emergency telecommand is transmitted autonomously. The satellite according to claim 5.

9. At least one tenant application among the plurality of tenant applications is configured to consume unallocated bandwidth from the communication link interface in response to detection of an emergency state. The satellite according to claim 1.

10. At least one tenant application among the plurality of tenant applications is configured to offload a task to another satellite. The satellite according to claim 1.

11. The satellite according to claim 10, wherein the task is offloaded by transmitting mission and / or task information to the other satellite via at least one of a ground station and a sidelink.

12. At least one of the plurality of tenant applications shares information with one or more neighboring satellites, and the information includes satellite ID, current position and orbital parameters, sidelink communication link parameters, communication link quality via sidelink, available and allowed data bandwidth, communication link quality, available and allowed data bandwidth from the neighboring satellite to the GS communication link (download and / or upload), mission functions of the satellite, sharable computing resources, sharable memory resources, at least one of sharable sensors, cameras, any HW accelerators, and payloads, sharable battery power resources, and includes data selected from, the satellite according to claim 1.

13. The satellite performs internal monitoring of the sharable computing resources, the sharable memory resources, the sharable sensors, the cameras, the any HW accelerators, the payload, the sharable battery power resources, and at least one of the plurality of tenant applications, the satellite generates data related to the internal monitoring, and communicates the data to the one or more neighboring satellites through at least one of an inter-satellite communication link (ISCL) and the ground station via a ground communication link, the satellite according to claim 12.

14. The satellite generates a routing table indicating characteristics of the shortest communication link between the satellite and one or more of the one or more neighboring satellites, and the satellite dynamically updates the routing table based on at least one of information received from one or more of the one or more neighboring satellites, information received from the ground station, and internal calculations of the positions of the neighboring satellites, the satellite according to claim 12.

15. The satellite generates a routing table indicating characteristics of a shortest communication link between the satellite and one or more of the ground stations via an inter-satellite communication link (ISCL) of the neighboring satellite, and the satellite dynamically updates the routing table based on information received from one or more of the one or more neighboring satellites and / or the information received from the ground station and / or internal calculations of the positions of the neighboring satellites. The satellite according to claim 12.

16. The information is shared via at least one of a sidelink and a ground station. The satellite according to claim 12.

17. The information is also shared with the ground station. The satellite according to claim 12.

18. When the data stored in the at least one memory is processed by the at least one processor, the satellite is capable of estimating the nearest and / or shortest sidelink paths of the neighboring satellites based on the orbital parameters of the neighboring satellites. The satellite according to claim 1.

19. The orbital parameters include at least one of a relative orbital time, a relative orbital distance, and a shortest network relay path. The satellite according to claim 17.

20. When the data stored in the at least one memory is processed by the at least one processor, the satellite is capable of generating and maintaining a shortest / nearest communication link path table. The satellite according to claim 1.

21. When the data stored in the at least one memory is processed by the at least one processor, the satellite is capable of performing a ground station communication link scan to identify a new ground station or a new neighboring satellite. The satellite according to claim 1.

22. A ground station, A satellite, A system comprising: The satellite includes: A communication link interface; At least one processor and at least one memory, and The at least one processor and the at least one memory are configured to support a plurality of tenant applications in a multi-tenant cloud computing environment, and two or more of the plurality of tenant applications establish independent communication link channels with the ground station using the communication link interface. System.

23. A payload that generates payload data, at least one processor, and at least one memory including data that enables the at least one processor to process commands from a plurality of users according to the same protocol and access the payload data, the payload, or both based on the processed commands. A satellite comprising the above.

Images