SGSS Impacts on Future SCCS-SM – Interim Report

1. SGSS Impacts on Future SCCS-SM – Interim Report John Pietras SMWG Berlin 15-20 May, 2011

2. Introduction • Space Network (SN) Ground System Sustainment (SGSS) Project to replace ground segment components of TDRSS • SGSS-era will support 5 SM interfaces: • Legacy “machine-machine interface” (MMI) for original TDRSS services • Legacy MMI for Demand Access System (DAS) extension to original TDRSS services • New web portal based “human-machine interface” (HMI) to provide SM capabilities for legacy services and new/enhanced SGSS capabilities • New messaged-based MMI with capabilities equivalent to HMI • New file-based MMI (details vague at this time) • SGSS is required to support SCCS-SM Blue-1 • SGSS Contractor has selected SCCS-SM as the basis for the new messaged-based MMI • SCCS-SM will be extended to meet the additional requirements of SGSS • SGSS extensions will be available as input to SCCS-SM Blue-2 • This report (presentation) summarizes SGSS requirements and Contractor decisions that will result in extensions to SCCS-SM Blue-1 as it applies to SGSS • Interim results as of early May 2011, subject to change and further refinement SMWG

3. But first …. • A few words about the proposed SN Service Management lifecycle SMWG

4. NIMO Major Process Steps* NETWORKS INTEGRATION MANAGEMENT OFFICE *From the presentation “Networks Integration Management OfficeMission Support Process” by the GSFC Networks Integration Management Office; Code 450.1, 5 April 2007 To be supported by “service management” SMWG

5. D+6 D+3 D-1 D-4 D-11 D-15 D-8 D-18 D-10 D-12 D-19 D-13 D+4 D-17 D+5 D+2 D-14 D-9 D-5 D-6 D-3 D-20 D-2 D D+1 D-21 D-16 D-7 Forecasting Scheduling Period Active Scheduling Period M T W T F S S M T W T F S S M T W T F S S M T W T F S S Target Week Typical Event Start Time Active Scheduling Period Data Base Maintained Active Schedule (Updates) Issued Schedule Requests Accepted and Processed Immediately SN Scheduling Timeline • SN segments scheduling into weekly periods that slide from forecast to active to operational (target) • Different scheduling rules apply to the different periods SMWG

6. … and now, back to our regularly scheduled program SMWG

7. SGSS SCCS-SM Operations Profile (1 of 2) • Service Package Service • Adopted • CSP,RSP, DSP, QSP, SPC, SPM • Excluded • SAS: no alternate scenarios • ANT: only one trajectory for each mission spacecraft • ANSLEP: Events Profiles will not be used • CTSP: SN will do rule-based scheduling, but scheduled Service Packaged (Events) will be automatically scheduled unless deleted via DSP • Not required by SCCS-SM because CSP is provided • Configuration Profile Service • Adopted • QSCSP, QTSP • Excluded • ASCSP, ASTSP, ARTSP: SN requirements limit creation of configuration profiles to SN operators • DSCSP, DSTSP, DRTSP: SN requirements limit deletion of configuration profiles to SN operators • ASLEP, DSLEP, QSLEP: Events Profiles will not be used SMWG Mandatory in SCCS-SM B-1

8. SGSS SCCS-SM Operations Profile (2 of 2) • Trajectory Prediction Service • Adopted • ETP, QTP • Excluded • ATP: Only one trajectory is maintained for each mission spacecraft. It is administratively created and extended via the ETP • DTP: The single (extended) trajectory prediction is maintained as long as the mission is supported by the SN • Service Agreement Service • Adopted • QSA SMWG

9. Service Package Service Constraints, Extensions, Modifications (1 of 6) • Increased flexibility in scheduling • Scheduling windows (existing SN capability) • A series of time-defined windows that specify when the requested Service Package can be scheduled • Resource constraints (new SGSS capability) • Allow multiple types/instances of SN resources to be specified as required, preferred, acceptable or unacceptable • Generalization of SCCS-SM antenna selection • Recurring schedule requests (new SGSS capability) • A form of rule-based scheduling in which the rules are conveyed as part of a recurring schedule request • A single recurring schedule request results in multiple Service Packages • Possible approaches • Extend CSP (this involves a number of issues) • Define a new operation (e.g., Create Recurring Service Packages) • Scheduling of Demand Access System (DAS) capabilities (existing SN capability) • Specific impacts have yet to be explored SMWG

10. Service Package Service Constraints, Extensions, Modifications (2 of 6) • Wait listing (existing SN capability) • UM can flag a service request to be put on a wait list if it cannot be scheduled during the initial scheduling attempt • CM will attempt to schedule the request until the expiration of the freeze interval (a parameter of the service request) • Alternatives (existing SN capability) • Allows schedule requests to be linked such that if the first request in the chain cannot be scheduled, the alternatives will be followed until one can be scheduled or the end of the chain is reached • S-Band power combining (current SN capability, extended for SGSS) • SN currently allows signals from S-Band multiple access (MA) and S-Band single access (SA) return services on a single TDRS to be combined • New SGSS capability will allow combining of any combination of MA and SA return services on any combination of TDRSs to be combined • SCCS-SM will have to be extended to support configuring multiple carriers across multiple antennas into a single data stream • Implemented as extensions to CSP, Space Communication Service Profiles, or both? SMWG

11. Service Package Service Constraints, Extensions, Modifications (3 of 6) • More-extensive Query Service Package status, e.g., • Query the status of all Established Service Packages • Query the identities of all Requested Service Packages • Query the identities of RSP-Is that have been acknowledged but not yet applied to the Established Service Package • Query the identities of all terminated Service Packages • Open issue: should query (or queries) return just status/identity or the full contents? • Aggregated schedules (existing SN capability) • Schedules that aggregate all service packages for a designated period (nominally a schedule week) • Open issues: • Should they be sent routinely by CM or in response to a query? • Should they contain just schedule-time-related information (comparable to CSP-SR) or all configuration parameters (comparable to QSP-SR)? SMWG

12. Service Package Service Constraints, Extensions, Modifications (4 of 6) • More interactions among Service Package operations • Allow CSP-I to be replaced before it has been scheduled • Allow RSP-I to be replaced before it has been scheduled • Allow RSP-I to be deleted before it has been scheduled • Issue: is only the RSP-I to be deleted (leaving the Established Service Package in place) or are both to be deleted? • Allow CM to act as proxy for UM in scheduling (policy of SN and SGSS) • Allow CM to schedule a Service Package on behalf of UM • Resultant Service Package could be notified to UM in a manner similar to whatever is used to identify recurring Service Packages (for SGSS) or using CTSP (for other users) • Allow CM to cancel a CSP-I or RSP-I before it has been scheduled • Allow CM to replace an established Service Package • Allow CM to replace a Requested CSP-I or RSP-I • …? Not in the initial version of the Interim Report SMWG

13. Service Package Service Constraints, Extensions, Modifications (5 of 6) • Space Link Carrier-level time flexibility (current SN capability) • SCCS-SM allows start time offset of carriers from the scheduled start time of the Space Communication Service within which they are contained • SN SM allows timing relationships among any space link carriers within the Service Package • Coupled to the start time of another carrier • Bound to be within the period of another carrier • Note: This may affect the way carrier profiles are defined • Use freeze interval for Service Package modification (current SN capability) • Notification when new trajectory data is applied (new SGSS capability) • “Hypothetical” Service Package requests (new SGSS capability) • Allow UM to submit requests against historic scheduling data to see how different applications of flexibility mechanisms would have yielded different results • Essentially a training tool, not an future support planning tool • Different from DSN notion of hypothetical plan SMWG

14. Service Package Service Constraints, Extensions, Modifications (6 of 6) • Management of offline storage • Legacy SN offline/playback services “push” a scheduled segment of playback data (from an single SN Event) at a scheduled time • SLE offline/CSTS complete services schedule the service instance provision period, but the user dynamically controls what data time segment is to be played back via the START operation of the transfer service • SGSS Contractor initially wanted to apply legacy push playback concepts to management of SLE services also • They are now beginning to understand the differences • Retrieval Service Packages and/or Retrieval Transfer Service Profiles will have to be extended to support push-oriented legacy playback services • Allow AR to be bypassed if the SR/FR can be sent within an AR timeout • Requires a separate AR timeout, which SCCS-SM had at one point • Applies to all 3-phase operations, not just Service Package service SMWG

15. Configuration Profile Service Constraints, Extensions, Modifications (1 of 2) • SN RF and modulation support • Extending existing CCSDS 401-based profiles (and agreements) would be awkward at best • Bilateral carrier profiles and transfer service profiles are probably the best candidates • Can be made to map more closely to SN service specification code (SSC) content and organization • Note: Data Transmission an PN Ranging for 2 GHz CDMA Link for Data Relay Satellite Red Book standardizes a subset of SN RF and modulation in SN terminology • At least some of the SN terminology will become CCSDS standard • SN tracking service configurations • Doppler or near-Earth PN ranging • Tracking data delivery via either CCSDS TDM or NASA legacy Universal Tracking Data Format (UTDF)-formatted data • Query groups of configuration profiles, e.g., • Query the identities of all available Space Communication Service Profiles (SCSPs) • Query the identities of all acknowledged ASCSP-Is • Query the identities of all deleted SCSPs SMWG

16. Configuration Profile Service Constraints, Extensions, Modifications (2 of 2) • Modification of Configuration Profiles (new with SGSS) • SGSS has requirements to allow UM to be able to modify “User Profiles” (which is being interpreted as including configuration profiles) but not to create or delete them • No guidance given for how much a profile can be modified • Issues regarding binding of Service Packages to potentially changing configuration profiles • SGSS Contractor likes SCCS-SM approach (no modifications, only creations and deletions) but feels required to allow modifications • Configuration profiles need to include simulation services (existing SN capability) and other test service (new for SGSS) • Configuration profiles need to include time calibration services • Return Channel Time Delay service • Time Transfer service • ROCF transfer service profile • SGSS will implement ROCF • Legacy transfer service configurations • Online (real-time) and offline (playback) SMWG

17. Trajectory Prediction Service Constraints, Extensions, Modifications • Default creation of Trajectory Prediction • ATP is not available to define the creator of the TP • Either exempt TPs from ownership enforcement if ATP is not used or specify default “owners” in the Service Agreement • Possible use for of QTP for Relay Satellite vectors (current SN capability) • SN must provide TDRS state vectors to user missions so that they know where to point their spacecrafts’ antennas • The TDRSs could be given “well known” TPids and their vectors could be queriable via the QTP • “Lack of Vector” notification (current DAS capability, to be extended to all Events/Service Packages in SGSS) • If Trajectory Prediction data is not available at TBD minutes before the start of execution of a Service Package, the “owner” is notified SMWG

18. Service Agreement Service Constraints, Extensions, Modifications • Modification of Service Agreements (new with SGSS) • SGSS has requirements to allow UM to be able to modify “User Profiles” (which is being interpreted as including Service Agreements) but not to create or delete them • No guidance given for how much a Service Agreement can be modified • Issues regarding binding of Service Packages and configuration profiles to potentially changing Service Agreements • SGSS Contractor likes SCCS-SM approach (no modifications) but feels required to allow modifications • Query groups of Service Agreements • In SCCS-SM B-1, the Service Agreement is the root of all identifications • Implies a more fundamental root, e.g., the [mission:Complex] pair SMWG

19. Additional Capabilities Beyond the Current SCCS-SM Service Management Services • Planning aids • TDRSS Unscheduled Time (TUT) (current SN capability, to be generalized in SGSS) • TDRS visibility (currently available for SN DAS users, to be available to all users under SGSS) • User performance data messages (current SN capability) • Periodic status monitoring reports sent periodically through the execution of the Service Package • User Performance Data Request message turns user performance data on/off • Acquisition failure notification message (current SN capability) • Notification sent when the return signal is not acquired by a specified time after the return • carrier has been activated • Time calibration service reports (current SN capability) • Single Return Channel Time Delay Measurement message (if scheduled) at the conclusion of the Event • Single Time Transfer message (if scheduled) at the conclusion of the Event • Real-time service control (current SN capability) • Post-Event accounting • Multiple but currently vague requirements to provide post-Event accounting reports to mission users SMWG

20. Some Things to Think About • What other TT&C networks are going to implement SCCS-SM Blue-1? • Are there any missions that will use the SN and other SCCS-SM Blue-1-compliant networks? SMWG