Overview of Functional Resources for IOAG Service Catalog Services 15 April 2013 Bordeaux, France John Pietras Global Science and Technology, Inc., Greenbelt, MD, USA

2 Purpose Explore and “prove” the proposition that the Functional Resources Types needed to compose the IOAG Service Catalog #1 services can be derived from the base set of Functional Resource classes To provide a “test bed” for analyzing the Functional Resource Types from a multi-service perspective  Identifies shared Functional Resources = production  Documented in Draft Technical Note “Functional Resources for Cross Support Services” (CSSA- CSS_FRs-TN-0.01, April 2013)

3 Agenda  Facets of a Functional Resource  Functional Resource Class diagram  Functional Resource Types for IOAG Service Catalog 1 (plus a few others)  Example IOAG SC #1 service compositions  Concluding comments

Facets of a Functional Resource  A Functional Resource is an abstraction of a cross-support function (processing step) performed on space communication or tracking data  If it is not visible at the cross support interface, it’s not a Functional Resource  Originally conceived as a framework for naming monitored parameters and notifiable events  Subsequently extended to include managed parameters (Service Management) and directives) real-time control 4 Functional Resource Instance space data to be processed processed space data managed parameters controlled parameters (directives) managed parameters notifiable events

Functional Resource Classes  Abstract classes are the extension mechanism for allowing new FR Types  Functional Resource Classes are abstract (non-instantiable)  Concrete (instantiable) Functional Resource Types are derived from Classes  Organized (roughly) in accordance with CCSDS taxonomy  Space Link Services  Transfer Services  Space Internetworking Services  IOAG Service Catalog #1 services correspond to single-hop space-ground services (also called the ABA configuration)  Services that are provided by a Complex in Cross Support Reference Model terminology  Services that are provided by an Earth-Space Link Terminal (ESLT) in Space Communications Cross Support Architecture terminology  ESLT is a component of a Provider Cross Support Service System (PCSSS), the SCCSA equivalent of the CSRM’s Complex 5

6 Functional Resource Classes for an ESLT

7 Functional Resource Types for IOAG Service Catalog #1 Services

Functional Resource Types for IOAG Service Catalog #1 Services – Forward 8

Functional Resource Types for IOAG Service Catalog #1 Services – Return 9

Example IOAG SC #1 Service Compositions 10  Forward Space Packet  (Future) Forward Frame  (Future) Forward File  Raw Data Radio Metric  Validated Data Radio Metric  Delta-DOR

11 Forward Space Packet (Forward Stack)  Forward Space Packet uses the full Telecommand (TC) stack  Most of the TC stack is shared production processing  Current Monitored Data Dictionary associates the production parameters with the FSP itself  Should they be available via the production FRs only, or via both production FRs and the transfer services that use them?

CLCW Feedback through Return Link 12  Do AOS Master Channels carry OCFs?  RID against AOS Space Data Link Protocol

(Future) Forward Frame Service (Forward Stack)  Non-dashed components provide Forward Synchronous Encoded Frame service  TC Frame Mode involves CLCW feedback 13

14 (Future) Forward File Service (Forward Stack)  Combinations of underlying protocol stacks leads to complicated Forward File service  IOAG SC1 calls for CFDP over Space Packet and Encapsulation, but only CFDP over Encap exists

(Future) Forward File Service (Return Link Feedback) 15  Forward File involves not only CLCW feedback (for Forward File service over TC stack) but also CFDP-PDU feedback (for Forward File over CFDP)

(Future) Return File Service 16  Combinations of underlying protocol stacks leads to similarly- complicated Return File service  Similar complications for Return File service

Raw Data Radio Metric 17

Validated Data Radio Metric 18  IOAG SC#1 only discusses delivery of validated data via file transfer service  Option to deliver over TD-CSTS (as illustrated here) is open for analysis

Delta-DOR 19  Very preliminary model  IOAG SC#1 limits separate D-DOR service to raw D-DOR data (validated D-DOR is assumed to be part of Validated service)  Correlation of D-DOR data is not addressed in the current Functional Resource Type set of ESLT – should it be?

Concluding Random Observations No notion of staging in the SCCS Architecture Return TS User class currently has only SLE ROCF (for 3-way COP); Other possibilities include TD-CSTS User for 3-way tracking (not shown in diagrams) 20