Document Control Data

Change History Log

Date	Revision	Author	Description of Changes
2013.10.08	DRAFT1	Ricardo Tubio	Initial DRAFT version.
2013.10.16	DRAFT2	Several authors.	Internal Polysat review.
2013.10.22	DRAFT	Ricardo Tubio	Minor changes and typo corrections.

List of Acronyms

AD	Applicable Document
API	Application Programming Interface
ASR	Availability and Scheduling Rules
	Set of rules that define the availability and scheduling for sharing a given ground station.
G-Client	Ground Station Client
	Software component of the SATNet network for ground station operators to share their facilities.
G-Client-IF	Ground Station Client Interface
	Communications interface provided by the SATNet network to the G-Clients.
G-Operator-UI	Ground Station Operator User Interface
	User interface for ground station operators to access to the services of the SATNet network.
ISP	Internet Service Provider
M-Client	Mission Operation Client
	Software component of the SATNet network for satellite operators to utilize remote ground station facilities.
M-Client-IF	Ground Station Client
	Communications interface provided by the SATNet network to the M-Clients.
N-System	Network Communications System
	Cloud-computing based component of the SATNet network for interconnecting G-Client(s) and M-Client(s).
Non-SCS	Non-Scheduled Communications Service
	Communications service provided by the SATNet network for permitting ground stations to store data received without previous request by spacecraft operators.
Pre-SCS	Pre-Scheduled Communications Service
	Communications service provided by the SATNet network for enabling the data messages exchange between spacecraft operators and ground stations.
RD	Reference Document
S-Operator-UI	Spacecraft Operator User Interface
	User interface for spacecraft operators to access to the services of the SATNet network.
SATNet	SATellite Network
SOR	Spacecraft Operation Request
	Request placed on the N-System by satellite operators for requesting the utilization of certain ground stations.
TBC	To Be Confirmed
TBD	To Be Determined
TBW	To Be Written
UHF	Ultra High Frequency

Applicable Documents

ID	Title	Reference	Author	Issue
AD-0	SATNet Project Management Plan	satnet-0-CoordinationPlan	CalPoly - [email protected]	TBD

Reference Documents

ID	Title	Reference	Author	Issue
RD-0	Space Engineering - System Engineering General Requirements	ECSS-E-ST-10C	ECSS - www.ecss.nl	C
RD-1	Space Engineering - Technical Requirements Specification	ECSS-E-ST-10-06C	ECSS - www.ecss.nl	C
RD-2	Space Engineering - Software	ECSS-E-ST-40C	ECSS - www.ecss.nl	C
RD-3	Space Engineering - Ground Systems and Operations	ECSS-E-ST-70C	ECSS - www.ecss.nl	C
RD-4	www.genso.org	GENSO	N/A

Object & Scope

• The object for this document is to establish a high-level specification of the interaction between users and the SATNet network. It also contains the definitions of the different actors that will utilize the network.
• Along the different reviews to be carried out on this document, the requirements and the high-level definition of the network may evolve and, therefore, may lead to changes in its implementation. These changes will be reflected in subsequent releases of the software.
• This document is divided in the following sections:
  1. A first section in which a network concept is provided, together with the actors and use cases involved in its operation.
  2. A second section that contains the user requirements baseline. This is a definition, in terms of user requirements, of the network concept provided in the previous section.
• The contents of this document are applicable along all the design and implementation cycle of the project. However, the final implementation of each of the features here proposed is subjected to the specific goals for each of the planned releases of the software.

Identification of User Needs

The design of this system is focused on addressing the needs of the CubeSat community when it comes to carry out the operations of their spacecraft. Current solution for this issue is based on the usage of amateur radio station in the UHF band used as standalone facilities. This way, CubeSats are normally operated once each orbit in the best of cases, even when no other limitation (such as low battery charge, for example) restricts their exploitation.

A typical CubeSat mission passes through the following two phases:

1. A first identification phase that takes place just after CubeSats are deployed into space. This phase may last a few weeks and, during that time, all CubeSats launched together are so close, that it is difficult for operators to command their spacecraft without interfering with others. When ground stations gather data from spacecraft that they do not expect to operate, that data is normally discarded or, in the best of cases, an email is sent with the notification of the data received, in case the owner of the spacecraft could be identified.
2. A second phase of nominal operations starts once the distance in between CubeSats is enough as for operators to command their spacecraft without creating such operational interferences. During this phase, operators utilize orbit predictions based on the two-line elements orbit definitions for tracking their spacecraft.

In this scenario, sharing CubeSat ground stations in between mission operators will permit increasing the available exploitation time of spacecraft. In the identification phase, the usage of multiple ground stations may suppose a shorter time of identification for a given spacecraft.

Users privacy must be preserved for those spacecraft operators who may not find appropriate that a network could track their connections with the ground stations. In this case, no entity but the communication ends involved, must have a direct knowledge on which ground stations are used for commanding a given spacecraft.

Direct connections may also be required by those users who would like to exchange data directly with ground stations. Possible applications may encompass high bandwidth communications (for example, raw baseband audio transmission), additional security requirements, long-duration data connections with ground stations... etc. For this communication scenarios, the network to be designed must provide services for the coordination of the nodes involved in this process.

In addition to all these user needs, support for experimental ground station scheduling and autonomous spacecraft operations, must be implemented on this network. This will permit certain universities to carry out scientific research on this system.

Network Concept

For the user needs identified in the section above, the SATNet network is intended to provide a flexible cloud-computing based solution. This solution will utilize its main cloud facilities for enabling CubeSat ground stations sharing through the Internet.

Unlike other projects like GENSO (see RD-04) in which only the authentication of ground stations and satellite operators was centralized, the solution here proposed will permit the exchange of data from the ground stations to the mission operators using the common cloud facilities. This way, it will provide a solution for those problems related to connection establishment due to intermediate firewalls and/or NAT address translation.

In addition to this, the data transmitted in between mission operation facilities and ground stations utilizing the services of the cloud, will be based on the usage of raw bitstream data. This approach permits the usage of a set of common facilities for handling data messages, since bandwidth requirements for these kind of communications can be achieved. In case some users require the exchange of raw audio data, the network will provide services for easing the establishment of direct connections among those nodes. This way, they will not collapse the common cloud facilities.

This network is data transport agnostic and it works as a simple message exchange service. The N-System never access to the data messages exchanged between those clients: it only distributes messages from one data source to a data sink, through the correspondent access interface.

Before start using the services of the network, ground station and mission operators must register in the system, so that they can get the certificates and keys required for authentication. Authentication, security and communications privacy is implemented by using a secure transport layer for ensuring that a private communications link is established in between network entities, regardless of whether they connect through the cloud system or through a direct connection.

Registration is also important for operators to define the capabilities of the ground station facilities and the communication needs (bandwidth, modulation, bitrate... etc.) of their spacecraft. This way, the common system can match the ground stations with those spacecraft that it can communicate with. Afterwards, this information will be utilized for presenting an autonomous selection of ground stations through which a given spacecraft can be operated.

Topology

The elements of the network concept are defined in the list below. This network will be composed of the following elements (concept definition is based on document [RD-03]):

• A set of software clients for spacecraft operators to command remotely the satellites. From now on, they will be defined as Mission Operations Clients or M-Clients for short.
• A set of software clients for providing direct access to the services of the ground station facilities. From now on, Ground Station Clients or G-Clients for short.
• A cloud system for the coordination of the communications in between these two types of clients. From now on, Network Communications System or N-System. It is important to note that the N-System is not a single server but a cloud-computing-based system. This way and depending on further implementation decisions, this cloud system may evolve into a network of interconnected servers that will provide the service required.

The N-System implements the following interfaces for permitting an automatic communication among software entities, without the need of direct human interaction:

• G-Client Interface (G-Client-IF), that permits the ground station clients to connect to the network services.
• M-Client Interface (M-Client-IF), that permits the mission operations clients to connect to the network services.
• Direct Client Interface (Direct-IF), that permits the mission operations clients to connect directly to the ground station clients.

The following diagram provides a graphical definition of the elements of the network and how they are interconnected with the given interfaces.

Since this system is expected to provide only interconnection capabilities for the ground stations and satellite operators, no support for the hardware of the G- or M- clients is to be provided. Therefore, ground stations and satellite operators must develop their own software and hardware equipment for using the services provided by the standard interfaces of the N-System.

Human Operators

The different operators involved in the usage of this network are the following (see figure on the following page):

• Ground Station Operator: this operator is responsible for the operation and maintenance of the G-Client. In addition to this, ground station operators are also responsible for registering their in the SATNet network, defining its ASR rules set and for keeping the registration information up to date.
• Satellite Operator: this operator operates a spacecraft using the M-Client and is also responsible for the registration of this client and of the spacecraft configuration in the network.
• Network Communications System Operator: this operator is responsible for the maintenance of the N-System and is the contact person for any problem in the usage of this system.

For permitting this interaction of the operators with the network, the following user interfaces are defined:

• Satellite Operator Service User Interface (S-Operator-UI), that permits satellite operators to access to the services of the N-System.
• Ground Station Operator Service User Interface (G-Operator-UI), that permits ground station operators to access to the services of the N-System.

Since the ground communications operator is a maintainer of the N-System, the definition of the access to the system that this actor has is a design issue for the specific implementation of that system.

Connection Establishment

The cloud computing approach utilized for this network permits avoiding some problems that appear when it comes to establish the connection in between network elements. In the main communications scenario, all network clients (either G- or M-) are required to establish the connect by themselves to this N-System, which must have a public IP address. This way, regardless of firewall(s) set up at intermediate network nodes and of the kind of IP address that each of the network clients have, the connection with the N-System is always possible.

For direct connections between two of the clients of the network, a process for determining who establishes the connection first, must be carried out. This process will depend on which of the nodes involved in the communication has a public IP address.

For those cases where no direct connection can be established in between both clients, the N-System must be used for exchanging data through the services that it provides.

Network Services

For implementing the network concept defined in the previous section, the SATNet network must provide the following services (classified in accordance with three categories):

• Management Services Category
  1. Registration Service.
  2. Configuration Service.
  3. Information Service.
• Scheduling Services Category
  1. Assisted Scheduling Service.
  2. Private Scheduling Service.
• Communication Services Category
  1. Assisted Communications Service.
  2. Private Communications Service.
  3. Non-Scheduled Communications Service.

Management Services Category

Registration Service

This service enables the registration of clients and operators in the network. The identity of both software clients and human operators must be verified at this point. Along this process, the exchange of keys and certificates for security issues must be carried out.

Configuration Service

Spacecraft operators must define the characteristics of the communications link that must be established in between remote ground stations and their satellite. This information will be later utilized for matching the ground stations that can operate this spacecraft from among the available ones.

Each ground station operator can define the Availability and Scheduling Rules or ASR rules for short, in the N-System. These rules define, in terms of time slots, the temporal availability of the ground station for remote operations. In addition to this, ground station operators may define additional rules that restrict the usage of their ground station facilities in terms different than the availability time.

Communications Channel Model

For matching the communications requirements of each spacecraft and the available capabilities of the ground stations, the following Communications Channel data structure is defined:

• Frequency range (in kilohertzs).
• Bandwidth range (in kilohertzs).
• Modulation (name).
• Bitrate range (in bits per second).
• Antenna polarization(s) (either LHCP, RHCP or linear).

This data structure is to be defined more precisely in the interfaces documents to be released.

Spacecraft Configuration Data

Mission Operators must provide the following data that defines the communication and tracking needs for a given spacecraft:

• Spacecraft Callsign
• Spacecraft TLE's Identification Code
• A list of the communication channels supported by the spacecraft, as defined in section above.

Ground Station Configuration Data

Mission Operators must provide the following data that defines the communication capabilities for a given ground station:

• Coordinates of the Ground Station location (latitude and longitude in degrees).
• Minimum elevation angle for contact (degrees).
• A list of the available communication channels supported by the spacecraft, as defined in section above.
• A list with the ASR rules that define how to share this ground station in the network.

Information Service

The objective of this service is to permit the automatic retrieval of public information concerning spacecraft and ground stations. This way, this service enables certain automatic scheduling and operations.

Data privacy requirements may apply and, therefore, spacecraft operators must decide which data they will publish in the network as public and which as private.

Scheduling Services Category

Assisted Scheduling Service

The planning for the operation of a spacecraft be based on the usage of the N-System is provided through this service. Spacecraft operators must beforehand, retrieve from the N-System the list of which ground stations will be available for the operation of their spacecraft and for how long (this is known as the operation slots list, or OSL for short). This list will be computed by the N-System taking into account:

1. spacecraft orbit predictions for tracking,
2. ground stations availability,
3. and communications compatibility between ground stations and spacecraft.

Once the available operation slots list is received by mission operators, they must select which of those slots they will need. The selection of the required operation slots must be sent back to the N-System for it to confirm whether this facilities are still available or not (other operators might have reserved them in the time elapse since the reception of the first list). The N-System will confirm the reservation of the ground stations required and will also coordinate those reservations with each of the ground stations. This is known as the Spacecraft Operation Request or SOR request for short.

During this process, G-Clients that can be connected through the Internet, can be marked for a direct connection. This way, at the given operation slots, the M-Client will connect directly to the ground station. In case the M-Client can be connected through the Internet, G-Clients will connect to it at the arranged time slots.

In case an unexpected event such as a problem with the ground station occurs, ground station operators can redefine its availability for marking the ground station as unavailable until the problem gets solved. The N-System will be responsible for the notification of this problem to those spacecraft operators that had already received a confirmation for the operation with those ground stations.

Private Scheduling Service

For preserving privacy during the scheduling of the ground stations, this service will assist the M-Clients in:

1. discovering the available ground stations,
2. in providing the information required for both clients to connect by themselves afterwards.

In this case, and depending on the connection capabilities of the clients, the N-System may have to request the connection of a set of ground stations to the initiator M-Client or not.

Communications Services Category

Assisted Communications Service

This communication service enables the exchange of data in between network clients by utilizing the N-System as a message exchanger. This will enable a real-time bidirectional communication in between ground stations and mission operation facilities. In this case, G-Clients will push data received from spacecraft on the N-System, and will also pull data that M-Clients had previously pushed. M-Clients will proceed in the same manner.

Private Communications Service

The Private-CS service permits a direct communications service in between G- and M- Clients. In this case, the exchange of data messages that shall be transmitted to the spacecraft or to the M-Client, are not exchanged through the usage of the N-System, but directly in between both communication ends.

The usage of this communications service requires that clients undergo a previous scheduling phase in which they must not only arrange the operation time slots, but also define which of them must establish the connection. During this phase, clients can use either the Assisted Scheduling Service or the Private Scheduling Service.

Non-Scheduled Communications Service

For the utilization of the Non-SCS service, ground stations will only have to provide both the data gathered and the reception context metadata for the cloud N-system to temporary store it. In case the metadata received is enough as for identifying the satellite that originated the transmission, the N-system will associate the data to that satellite. Once the operator of that satellite connects to the system, a notification will be sent and data will be available for retrieval through the M-client.

Use Cases

Management Services

The two use case diagrams contained in this section define the way in which Ground Station and Mission Operations (both software clients and operators) must access to the management services. In addition, it also models the way in which they will coordinate certain system usages with the operator of the N-System.

Typical Remote Spacecraft Operation

This use case defines how to use this network for the typical remote spacecraft operation. It has been identified as the main communications scenario for this network.

Private Remote Spacecraft Operation

This use case models the usage of this network when it comes to schedule the remote utilization of ground stations, by invoking the assisted scheduling service. The difference with the typical remote spacecraft operation is that the service required for communications is the private communications service.

During the usage of the assisted scheduling service, the M-Client must mark the time slots as requested for private communication. This way, and depending on whether the M-Client or the G-Client(s) have a public IP address, the N-System will assist them in arranging also which of the clients must start the connection.

Non-Scheduled Spacecraft Operation

This is the typical use case to be utilized during the first phase of the operation of a CubeSat, when operators cannot distinguish which is their spacecraft and, therefore, do not need a bi-directional communications service.

Private Scheduling and Remote Operations

In this scenario, users both utilize the private scheduling and private communications service. Since the N-System will only provide information during the private scheduling service, two different cases have to be taken into account for the definition of who initiates the starts the connection establishment:

1. In case a M-Client makes this request and it has not a public IP address, this client must try to connect by itself to the G-Clients. The N-System will only provide the list of available G-Clients that have a public IP address. Therefore, the M-Client will be responsible for the establishment of the connection both during the scheduling and the communications phase.
2. In case a M-Client makes this request and it has a public IP address, G-Clients must establish the connection. For this, the N-System must send a request to all available G-Clients for them to contact the M-Client afterwards.

These two possibilities are graphically defined in the figures below in this section.

User Requirements Baseline

General Requirements

• This section contains a set of high-level requirements that define the general aspects of the system.

USR-GEN-010	System Objective
	The SATNet network shall provide a system for interconnecting ground stations with satellite operators through the Internet.
USR-GEN-020	Satellite Data
	The SATNet network shall not access to the data either transmitted from the spacecraft or from the mission operation facilities.
USR-GEN-030	System Monitoring
	The SATNet network shall permit a monitoring of its execution, performance and user access.
USR-GEN-040	Hardware and Software Support
	The SATNet network shall neither provide hardware nor software support to ground station operators or to satellite operators.
USR-GEN-050	Documentation License
	The documentation for the SATNet project shall be distributed under Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license.
	NOTE: For further details on the usage of this license, see [http://creativecommons.org/licenses/by-sa/3.0/deed.en_US].
USR-GEN-060	Software Development License
	The software developed for the SATNet network shall be licensed in accordance with the version 2.0 of the Apache Software License.
	NOTE 1: The usage of this software license will guarantee: 1) the preservation of the rights of the original author of the code without concern for royalties, 2) the free distribution of the original software code for its subsequent modification, 3) the possibility of linking from code regardless of its development license, and 4) further license modifications in derivative works.
	NOTE 2: For more details about the version 2.0 of the Apache Software License, see [http://www.apache.org/licenses/].
USR-GEN-070	Design evolution
	The design of the SATNet network shall evolve as new user needs and/or requirements are identified.
USR-GEN-080	System Implementation
	The implementation of the SATNet network shall permit a continuous evolution of the system.
USR-GEN-090	System Development
	The development of the SATNet network shall follow a software engineering process that implements an evolutionary implementation of the required features.
USR-GEN-100	Design Justification
	All design and implementation assumptions shall be dully justified.
USR-GEN-110	Security Measures
	The security measures implemented for this network shall not preclude potential user groups.
USR-GEN-120	Exploitation Time
	The exploitation time for the SATNet network shall be 2 years (TBC).
USR-GEN-130	Releases Schedule
	The releases for the network shall follow the schedule defined in section Roadmap of document AD-00.
	NOTE: On this date, the SATNet system shall not be fully operational but shall, at least, permit a regular operation of a CubeSat with a remote compatible Ground Station.
USR-GEN-140	Network Validation
	The implementation of each of the releases of the SATNet network shall be validated in accordance with an Integration and Validation Plan.

System Access and Security Requirements

• This section contains a definition of the access mechanisms that the network enables for users to access to its services.

USR-ACC-010	User Access
	The design of the SATNet network shall allow users to access the services provided through tools developed by themselves.
USR-ACC-020	User Access - Medium
	The SATNet network shall provide access to the services of the network through the Internet.
USR-ACC-030	User Access - API
	A public definition of the API shall be released for users to access to the services of the network.
USR-ACC-040	User Access - API updates
	The public definition of the API shall be updated as changes in the access services are required for accessing the network.
USR-ACC-050	User Access - API changes
	Future changes in the API of the network services shall be announced in advance together with the correspondent API update.
	NOTE: This guarantees that users will have time enough for adapting their access tools before the network itself implements those changes.
USR-ACC-060	User Authorization
	The SATNet network shall provide access only to users who have previously registered and whose registration had been approved.
USR-ACC-070	User Identification
	The SATNet network shall provide access only to users whose identity had been unambiguously verified.
USR-ACC-080	Network Authentication
	The SATNet network shall implement a mechanism for unambiguously identifying itself to the users of the network.
USR-ACC-090	Network Authentication
	The SATNet network shall implement a mechanism for unambiguously identifying itself to the users of the network.
USR-ACC-100	Data Privacy - Storage
	The SATNet network shall guarantee the privacy of the data stored within the network.
USR-ACC-110	Data Privacy - Communications
	The SATNet network shall guarantee the privacy of the data exchanged through the communications carried out along the network.
USR-ACC-120	Data Integrity - Storage
	The SATNet network shall guarantee the integrity of the data stored within the network.
USR-ACC-130	Data Integrity - Communications
	The SATNet network shall guarantee the integrity of the data exchanged through the communications carried out along the network.
USR-ACC-140	Data Authenticity - Storage
	The SATNet network shall guarantee the authenticity of the data stored within the network.
USR-ACC-150	Data Authenticity - Communications
	The SATNet network shall guarantee the authenticity of the data exchanged through the communications carried out along the network.

Service Provision Requirements

• This section contains a definition of the requirements that define how the network provides its services, in terms of availability, general functionality and performance.

USR-SRV-010	Network Services
	The SATNet network shall provide the following services:
	1. Registration service
	2. Configuration service
	3. Information service
	4. Assisted Scheduling Service
	5. Private Scheduling Service
	6. Assisted Communications Service
	7. Private Communications Service
	8. Non-Scheduled Communications Service
USR-SRV-020	Backwards Compatibility
	The implementation of new definitions or updates of the network services shall preserve the compatibility with previous versions.
USR-SRV-030	Authentication
	Service provision shall only start after both communication ends had been authenticated.
USR-SRV-040	Security
	Service provision shall be provided only through ciphered communication channels.
USR-SRV-050	Registration Service - Definition
	The registration service shall permit mission and ground station operators to register them in the network.
USR-SRV-060	Registration Service - Implementation
	The registration service shall be implemented by the N-System.
USR-SRV-070	Registration Service - Interfaces
	The registration service shall be accessed through the G-Operator-UI and M-Operator-UI interfaces.
USR-SRV-080	Configuration Service - Definition (1)
	The configuration service shall permit the definition of the capabilities of ground station facilities.
USR-SRV-090	Configuration Service - Definition (2)
	The configuration service shall permit the definition of the communication needs of spacecraft.
USR-SRV-100	Configuration Service - Definition (3)
	The configuration service shall permit the definition of the ASR rules for a given ground station.
USR-SRV-110	Configuration Service - Implementation
	The configuration service shall be implemented by the N-System.
USR-SRV-120	Configuration Service - Interfaces (1)
	The configuration service shall be accessed through G-Operator-UI and M-Operator-UI interfaces.
USR-SRV-130	Configuration Service - Interfaces (2)
	The configuration service shall be accessed through G-Client-IF and M-Client-IF interfaces.
USR-SRV-140	Information Service - Definition
	The information service shall permit users to retrieve information about registered ground stations and spacecraft .
USR-SRV-150	Information Service - Implementation
	The configuration service shall be implemented by the N-System.
USR-SRV-160	Information Service - Interfaces
	The configuration service shall be accessed through G-Client-IF and M-Client-IF interfaces.
USR-SRV-170	Assisted Scheduling Service - Definition (1)
	The assisted scheduling service shall provide a list of available time slots for a given spacecraft, upon a request made a M-Client.
USR-SRV-180	Assisted Scheduling Service - Definition (2)
	The assisted scheduling service shall permit a M-Client to place a SOR request with the time slots that it requires.
USR-SRV-190	Assisted Scheduling Service - Definition (3)
	The assisted scheduling service shall confirm the time slots required by a given M-Client with the ground stations.
USR-SRV-200	Assisted Scheduling Service - Definition (4)
	The assisted scheduling service shall notify to the M-Clients the final time slots that could be reserved in the ground stations.
USR-SRV-210	Assisted Scheduling Service - Definition (5)
	The assisted scheduling service shall permit M-Clients to mark the requested slots as private, whenever they would like to establish a private communication with the ground station.
USR-SRV-220	Assisted Scheduling Service - Definition (6)
	The assisted scheduling service shall provide a list of the available ground stations that have a public IP address.
USR-SRV-230	Assisted Scheduling Service - Definition (7)
	The assisted scheduling service shall request the connection of a G-Client back to a M-Client for a private scheduling service to be established.
USR-SRV-240	Assisted Scheduling Service - Implementation
	The N-System shall implement the assisted scheduling service.
USR-SRV-250	Assisted Scheduling Service - Interfaces (1)
	The assisted scheduling service shall be accessed through the G-Operator-UI and M-Operator-UI.
USR-SRV-260	Assisted Scheduling Service - Interfaces (2)
	The assisted scheduling service shall be accessed through the G-Client-IF and M-Client-IF.
USR-SRV-270	Private Scheduling Service - Definition (1)
	The private scheduling service shall be carried out by G- and M- Clients without the usage of the services implemented by the N-System.
USR-SRV-280	Private Scheduling Service - Definition (2)
	The private scheduling service shall be carried out after authentication in between entities.
USR-SRV-290	Private Scheduling Service - Definition (3)
	The private scheduling service shall permit the negotiation of the operation time slots in between a G-Client and a M-Client.
USR-SRV-300	Private Scheduling Service - Implementation
	G-Clients and M-Clients shall implement the private scheduling service.
USR-SRV-310	Private Scheduling Service - Interfaces
	The private scheduling service shall be accessed through the Direct-IF.
USR-SRV-320	Assisted Communications Service - Definition (1)
	The assisted communications service shall provide bi-directional and real time data message exchange between G- and M- Clients.
USR-SRV-330	Assisted Communications Service - Definition (2)
	The assisted communications service shall permit M-Clients to check whether G-Clients have already connected to the N-System, before they start the remote communications.
USR-SRV-340	Assisted Communications Service - Definition (3)
	The assisted communications service shall permit M- and G- Clients to notify to the other end of the communication, any error that may occur during the remote operation.
USR-SRV-350	Assisted Communications Service - Implementation
	The assisted communications service shall be implemented by the N-System.
USR-SRV-360	Assisted Communications Service - Interfaces
	The assisted communications service shall be accessed through the M-Client-IF and G-Client-IF.
USR-SRV-370	Private Communications Service - Definition (1)
	The private communications service shall be carried out by G- and M- Clients without the usage of the services implemented by the N-System.
USR-SRV-380	Private Communications Service - Definition (2)
	The private communications service shall be carried out after authentication in between entities.
USR-SRV-390	Private Communications Service - Definition (3)
	The private communications service shall permit data exchange between a G-Client and a M-Client.
USR-SRV-400	Private Communications Service - Implementation
	G-Clients and M-Clients shall implement the private communications service.
USR-SRV-410	Private Communications Service - Interfaces
	The private communications service shall be accessed through the Direct-IF.
USR-SRV-420	Non-Scheduled Communications Service - Definition (1)
	The non-scheduled communications service shall permit ground stations to store data gathered from an unknown spacecraft, together with the metadata describing the reception context.
USR-SRV-430	Non-Scheduled Communications Service - Definition (2)
	The non-scheduled communications service shall permit mission operators to retrieve the data that a ground station stored in the network, only from a spacecraft that they own.
USR-SRV-440	Non-Scheduled Communications Service - Implementation
	The non-scheduled communications service shall be implemented by the N-System.
USR-SRV-450	Non-Scheduled Communications Service - Interfaces
	The non-scheduled communications service shall be accessed through interfaces G-Client-IF and M-Client-IF.

Implementation Requirements

• This section contains all the requirements that restrict the implementation process of the SATNet network.

USR-IMP-010	Satellite Protocol Agnostic
	The data transport carried out by the SATNet network shall be independent of the protocol utilized for the communications in between the mission operation facilities and spacecraft.
USR-IMP-020	Network Scalability
	The design of the SATNet network shall permit the scalability of the service provision.
	NOTE: This way, increases in the network load can be solved without the need of carrying out a redesign of the architecture of the network.
USR-IMP-030	M-Client Implementation (1)
	The implementation of the M-Client shall be carried out by each satellite operator.
USR-IMP-040	M-Client Implementation (2)
	The implementation of the M-Client shall meet the requirements to access the services of the SATNet network, as per document TBD.
USR-IMP-050	G-Client Implementation
	The implementation of the G-Client shall be carried out by each ground station operator.
USR-IMP-060	G-Client Implementation (2)
	The implementation of the G-Client shall meet the requirements to access the services of the SATNet network, as per document TBD.
USR-IMP-070	N-System Implementation
	The implementation of the N-System shall meet the requirements for implementing the access interfaces of the services, as per documents TBD and TBD.
USR-IMP-080	Embedded G-Client(s)
	The G-Client-IF implemented by the N-System shall permit a lightweight access to the services provided.
	This will permit embedded systems to access to the network services.
USR-IMP-090	Use Case Implementation
	G-Clients, M-Clients and the N-System shall implement the use cases as defined per section "Use Cases" of this document.