NASA Space Network Ground Segment Sustainment (SGSS) Schedule Request SMWG Boulder, CO 31 October – 4 November 2011 John Pietras GST, Inc.

2 Agenda  Purpose  Background  Approach  Schedule Request Class Diagrams

33 Purpose  To describe the (still evolving) NASA Space Network Ground Segment Sustainment (SGSS) Project requirements for a “schedule request message”  Compare the draft SGSS schedule request message with the SCCS-SM-B-1 Create Service Package invocation

4 Background  The proposed Blue-2 refactoring approach provides a framework adding new managed services and extending the managed services already covered by Blue-1  NASA SGSS is to implement SCCS-SM Blue-1 “to the greatest extent possible”, but SGSS will have schedule optimization mechanisms that are not supported by Blue-1’s Create Service Package operation

Approach  Develop SGSS Schedule Request class diagrams equivalent to that of the Space Link Session Service Package Request selection in the > of SCCS-SM-B-1  Based on draft SGSS schema of 6 September 2011  Class diagram view is easier to see “big picture” concepts than schema details  Easier to compare to > class diagram  Covers only those features of importance to SGSS  No attempt (in this iteration) to add back SCCS-SM-B-1 features not used by SGSS  SCCS-SM refactoring concepts applied where it seems appropriate  A few minor differences between classes and schema types for purposes of cleaner class diagram representation 5

> Class Diagram 6

SGSS Schedule Request (Top Level) 7

SGSS Schedule Request Comparison with CSP  No alternate scenarios  SN will implement only a single “scenario”  No explicit trajectory references  SN uses maintains a single trajectory for each supported spacecraft  Freeze interval parameter regulates how long CM can modify a request  Request can be for a single (specific) service package or a recurring service package  The specific request as a whole has a start time that is requested  In contrast with the CSP, in which the components of the request have start times and the start time of the service package is result of what is scheduled  The start time can be around a single (preferred) start time or within any of a set of start time windows  The specific request can be constrained to be within one of a defined set of windows  The SN groups services (carriers) by Event (the group of services provided through a single TDRS), not by single antenna (as in SCCS-SM SCSP)  Antenna selection is addressed later  Multiple events can be specified within the request, but one is primary ands the others are “linked” to it  No reason to put multiple events in the same package unless they are somehow related 8

Time Window Classes 9

Recurrent Time 10

Event Specification 11 points to Event Specification Profile points to User Service Profile

Service Specification Comparison with CSP  In today’s SN, services (carriers) in an Event can be specified either individually, or grouped in a pre-defined Prototype Event  Service (carrier) configuration parameters can be respecified only when the services are explicitly defined in the request  The Prototype Event notion is carried in SGSS as the Referenced Event Specification  SCCS-SM provides for scheduling groups of services (via predefined Space Communication Service Profiles), and allows respecification of parameters within those groups  This leads to a more-complicated respecification mechanism  Can/should Blue-2 adopt the simpler SN/SGSS approach? 12

Service Specification 13

Service Specification Comparison (continued)  Services can be related to each other  Alternative  Coupled  Bound  In SCCS-SM, all carriers can only be offset by a fixed time from the scheduled start time of the Space Communication Service 14

Event Specification Profile 15

Linked Event 16