Scheduling Bazaar

The Libre Space Foundation’s SatNOGS project seeks to open access to space-related information by creating an ecosystem of open source software and hardware components. The SatNOGS project accomplishes this goal by reducing the cost of owning a satellite ground station and providing software tools to automatically manage the creation and execution of satellite observations.

The libre philosophy of the project acknowledges the liberty of a ground station owner to operate their station as they see fit. Generally, these owners are interested in making their station available for others to schedule observations during times when the station is not being actively controlled.

SatNOGS is the first operational network for coordinating ground stations using an open model and especially one focused on free and open source development. To remain the leaders in this area, SatNOGS should also create, specify, and provide the reference implementation for the interactions between a Network and Client. Having a stable Network←→Client interface is a key step to promoting interoperation or federating between more stakeholders.

Since SatNOGS' conception, however, there have been several ground station network alternatives with various stages of development, capabilities, and goals — in various combinations of proprietary / open and commercial / non-commercial. By publishing both the minimum requirements for interoperation and providing a body of reference code, the SatNOGS community can materially reduce or reverse the fracturing happening in this arena. There is arguably progress in this area at this time (2019), but there are still areas open for taking a leadership role.

Currently, the SatNOGS Client component has no decision-making capability, it accepts all jobs assigned to it from the SatNOGS Network. There is no mechanism to assist an Observer in scheduling observations that are compatible with an Owner’s preferences or other priorities such as launches, special satellite operations. This higher level of scheduling strategy depends on Observer familiarity of these desires and has been an issue within the community. Also, the auto-scheduler, as currently implemented, only automates scheduling observations on stations from one Owner using that Owner’s prioritized preferences.

In addition, there is not a clear way for describing the priorities of a Network, a ground station Owner, or an Observer to help deal with overlaps in passes. This issue prevents acceptable automation of job scheduling, since such a system would need to know all participants' priorities and authorizations in order to find an optimal schedule.^[1]

The current job scheduling system does not (easily) allow a particular Client to schedule jobs in cooperation with other networks (including switching to transceiver mode when an Owner is also a satellite control operator). Such behavior should be allowed to respect and reinforce the Owner’s right to operate their station as they see fit.

A request process should happen between a Network and Client where both parties arrive (or not) at an agreement on the set of details for a requested Job. Either side of the negotiation may respond with a modified set of details corresponding to a more desirable request. A Job is only considered as scheduled when one side indicates agreement via an accept response which references the Network-unique id of a specific received request.

The Network and Client initiate the scheduling of a Job and indicate their preferences to each other by:

The bounty is a list of one or more key:value pairs, where each pair has a Network-specific meaning. Accounting for these values depends on a specific Network’s policies and any direct agreements (contracts) between a Network and Owner.

Work building a simulator to model this multi-agent system is ongoing and lives at https://github.com/wiredlab/scheduling-bazaar.

The software implementing the Client enables an Owner to specify an ordered list of satellites, or provide a callback function which implements a more complex local policy. This is similar to the current satnogs-auto-scheduler.

The SatNOGS Network could offer SNC set to the duration in minutes for a particular job, which would accumulate in the Owner’s user account (think leaderboard statistics and ability to schedule on other stations). Non-Owners can use SNC`s to increase the offered `bounty for particular requests. Absent a conflicting Owner preference, the Client may naturally choose the set of overlapping requests which maximizes the total SNC value. In this scenario, a Client can detect that someone wants this particular observation when the offered SNC is larger than the pass duration, which may be useful information to an Owner.

An Owner is particularly interested in a certain satellite. They will configure their Client(s) to accept requests for observations of this satellite and reject any requests which overlap with those passes. Upon receiving a request from a Network for a non-priority satellite, the Client may make a modified request back to the Network with modified times which no longer overlap with the priority Job. The requesting Network may then choose to accept or reject the modified request. The Owner may also maintain a local Network instance to accept Jobs that no other Network will take or to act as a local archive.

The OURSAT Network has entered into agreements with several Owners/Clients for making observations of OURSAT’s satellite(s). Part of the agreement involves payments to an Owner for jobs observing an OURSAT satellite. The agreement does not restrict the observation data. In this case, the Client might accept requests from OURSAT Network and then make a request to the SatNOGS Network for the same job. The net result is OURSAT gets priority scheduling with a certain Client and the observation data is also made available to all via the SatNOGS Network.

An agreement between the Owner and Spam Network prohibits the disclosure of the request data to other parties and also prohibits a Client from uploading received Observation data to other Networks. The information contained in the request object from Foo Network may be proprietary. This scenario still allows the Client to accept Jobs from other Networks for unrelated observations.

Another Network (¿SatNOGS Pro?) operates as a data service provider for Satellite Operators or third parties interested in specific Observations — Observations as a Service (OaaS). Nothing prevents an Owner’s right to use their Client to earn a nominal remuneration for providing observation data. Also, nothing prevents a Client from scheduling the same Job with several Networks, besides an exclusion clause in a Network-Owner contract, which would be allowed but discouraged. In this example, a Client would by default schedule Jobs with SatNOGS Network, but would schedule Jobs with monetary value with another Network. Then the Client would send the same Job information as a request to SatNOGS Network which would respond with an additional item in the bounty list or simply not reply if not interested.